fix: ignore stale approval resolve errors#98394
Conversation
|
Codex review: needs maintainer review before merge. Reviewed July 5, 2026, 5:59 PM ET / 21:59 UTC. Summary PR surface: Source -4, Tests +225, Docs +1. Total +222 across 4 files. Reproducibility: yes. at source level. Current main can write a global approval error for an older id that remains anywhere in the queue while the component renders that error on the newer active prompt; I did not run the browser repro in this read-only pass. Review metrics: none identified. Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Next step before merge
Security Review detailsDo we have a high-confidence way to reproduce the issue? Yes, at source level. Current main can write a global approval error for an older id that remains anywhere in the queue while the component renders that error on the newer active prompt; I did not run the browser repro in this read-only pass. Is this the best way to solve the issue? Yes for the runtime fix. Scoping resolve results to the operation's client and active approval id is narrower than view-only filtering or gateway changes, but the release-owned changelog edit should be removed. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 1a37cafd63b6. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source -4, Tests +225, Docs +1. Total +222 across 4 files. View PR surface stats
What 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
Review history (1 earlier review cycle)
|
Co-authored-by: haruaiclone-droid <[email protected]>
580a3e7 to
7d625a4
Compare
|
Maintainer verification complete on rewritten head
Known proof gaps: none for the touched Control UI surface. Ready for exact-head CI and landing. |
|
Merged via squash.
|
* fix(ui): scope approval decision results Co-authored-by: haruaiclone-droid <[email protected]> * docs(changelog): credit approval race fix --------- Co-authored-by: Peter Steinberger <[email protected]> Co-authored-by: haruaiclone-droid <[email protected]>
Closes #98392
AI-assisted: Yes (Codex)
What Problem This Solves
An approval resolve can finish after a newer approval becomes active or after the Control UI reconnects. The older completion could attach its error to the wrong prompt, or clear the busy state owned by a newer decision.
Why This Change Was Made
Approval decisions now have an explicit operation owner: the exact Gateway client and approval id that started the request. Only that operation may release the busy state. Non-stale failures are shown only while the same client and approval remain active. This keeps reconnect and queue transitions on one canonical ownership path instead of adding error-specific fallbacks.
User Impact
Operators no longer see a stale approval error on a newer prompt, and an older request cannot re-enable controls while a newer approval decision is still in flight.
Evidence
tbx_01kwt3gy25f6vrxsven71k22mz:corepack pnpm test ui/src/app/overlays.test.ts(2/2 pass).node scripts/run-vitest.mjs run --config test/vitest/vitest.ui-e2e.config.ts --configLoader runner ui/src/e2e/approval-flow.e2e.test.ts(Chromium, 1/1 pass).corepack pnpm check:changed(pass).origin/main: no accepted/actionable findings.git diff --check(pass).