perf(update): reuse missing plugin payload id set#96950
Conversation
|
Codex review: needs real behavior proof before merge. Reviewed June 26, 2026, 5:27 PM ET / 21:27 UTC. Summary Reproducibility: not applicable. this is a performance cleanup rather than a bug report. The source path and tests show the membership behavior, but the external PR still needs real after-fix update or repair proof before merge. Review metrics: 1 noteworthy metric.
Stored data model Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Keep the narrow Set reuse, require redacted real update or repair proof, then merge the actual one-file delta once routine checks are green. Do we have a high-confidence way to reproduce the issue? Not applicable; this is a performance cleanup rather than a bug report. The source path and tests show the membership behavior, but the external PR still needs real after-fix update or repair proof before merge. Is this the best way to solve the issue? Yes, the actual merge delta is the narrow maintainable fix because the downstream API already consumes a AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 29680046801d. Label changesLabel justifications:
Evidence reviewedWhat I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
|
Merged via squash.
|
* perf(update): reuse missing plugin payload id set * perf(update): reuse missing plugin payload id set --------- Co-authored-by: ly-wang19 <[email protected]> Co-authored-by: Vincent Koc <[email protected]>
* perf(update): reuse missing plugin payload id set * perf(update): reuse missing plugin payload id set --------- Co-authored-by: ly-wang19 <[email protected]> Co-authored-by: Vincent Koc <[email protected]>
* perf(update): reuse missing plugin payload id set * perf(update): reuse missing plugin payload id set --------- Co-authored-by: ly-wang19 <[email protected]> Co-authored-by: Vincent Koc <[email protected]>
* perf(update): reuse missing plugin payload id set * perf(update): reuse missing plugin payload id set --------- Co-authored-by: ly-wang19 <[email protected]> Co-authored-by: Vincent Koc <[email protected]>
What Problem This Solves
The post-core update plugin repair path collected missing plugin payload IDs as an array, then used that list both to build a skip set and later to suppress duplicate remaining-payload warnings. The second use performed repeated linear membership checks.
Why This Change Was Made
This stores the collected missing payload IDs as a Set immediately, then reuses that Set for both downstream skip ID construction and duplicate-warning suppression. The behavior stays the same while lookup cost stays constant as the missing payload list grows.
User Impact
Plugin update repair bookkeeping does less repeated work when many plugin payloads are missing or repaired during an update. User-visible warning behavior is intended to remain unchanged.
Evidence