refactor(gateway): centralize agent wait lifecycle#104147
Conversation
|
Codex review: needs maintainer review before merge. Reviewed July 11, 2026, 1:12 AM ET / 05:12 UTC. Summary PR surface: Source -358, Tests +35. Total -323 across 9 files. Reproducibility: not applicable. as a user-facing bug reproduction; the duplicated lifecycle ownership is directly established by current source, and the PR's disagreement tests exercise the ordering invariants that motivated the refactor. Review metrics: 1 noteworthy metric.
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. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Maintainer decision needed
Security Review detailsBest possible solution: Approve one canonical agent-job registry as the permanent owner, retaining the shared terminal-outcome merger and focused collision, retry-grace, timeout, cached-wait, and waiter-cleanup coverage as its contract. Do we have a high-confidence way to reproduce the issue? Not applicable as a user-facing bug reproduction; the duplicated lifecycle ownership is directly established by current source, and the PR's disagreement tests exercise the ordering invariants that motivated the refactor. Is this the best way to solve the issue? Yes. Consolidating the state owner is narrower and more maintainable than extracting or preserving the handler-level race, and the repaired head reuses the canonical precedence helper instead of creating a parallel policy. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 8f8aad9ae692. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source -358, Tests +35. Total -323 across 9 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 (6 earlier review cycles)
|
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
Landed via squash onto
|
* refactor(gateway): centralize agent wait lifecycle * fix(gateway): preserve agent wait freshness --------- Co-authored-by: Ayaan Zaidi <[email protected]>
Closes #104135
What Problem This Solves
Resolves an internal Gateway reliability problem where
agent.waitreconciled two independent terminal-state owners: lifecycle observations in the agent job cache and terminal Gateway dedupe entries. Each path maintained its own waiter machinery, and the RPC handler raced both promises before deciding which result won.Why This Change Was Made
The agent job registry now ingests both lifecycle and dedupe terminal observations, applies the existing canonical terminal-outcome precedence, and owns the only waiter registry. A closed source tag preserves the existing active-chat/run-ID collision behavior. The separate dedupe wait module, handler-level
Promise.race, and dead cancellation path are removed.User Impact
No intended user-visible behavior change. Agent waits now have one deterministic terminal-state owner, while Gateway event fan-out no longer registers one global agent-event listener per waiter.
Evidence
tsgolanes passed. The environment stopped externally during later full-core lint stripes, so no fullcheck:changedclaim is made.origin/mainand stop before scenarios because the current release changelog section is missing.chat.sendwith two concurrent waits plus a cached wait.ok, the Gateway remained healthy afterward, and logs contained no crash markers.Sanitized process-level results:
{ "completion": { "cliAgent": "ok", "agentConcurrentWaits": ["ok", "ok"], "agentCachedWait": "ok", "chatConcurrentWaits": ["ok", "ok"], "chatCachedWait": "ok", "providerRequests": 3, "gatewayHealthyAfterRuns": true, "crashMarkers": false }, "timeout": { "agentConcurrentWaits": ["timeout", "timeout"], "agentCachedWait": "timeout", "gatewayHealthyAfterRun": true, "crashMarkers": false } }AI-assisted: implementation delegated to an agent, then source-reviewed and verified before push.