🤖 fix: session disposal does not wait for a stopping migration

[ThomasK33]

Summary

Since #5579, a refused or failed background migration whose exit is never confirmed stays pending for the rest of the backend process. Session disposal's cleanup(workspaceId) drains pending entries with no deadline, so it hung forever and kept its admission seal. After that, every later move to the background in that workspace was refused, and session.end and listener removal never ran. Now session disposal does not wait for a migration whose command is being stopped. It finishes and releases its seal. Removal and archive still wait for that migration and fail closed at their 60 s drain deadline.

Fixes #5589

Implementation

• beginMigration() returns a markStopping(). The bash tool calls it where it hands a refused or failed migration to the command's exit (🤖 fix: keep a refused or failed migration pending until its command exits #5579).
• The manager remembers stopping entries in a WeakSet beside the existing pending set. No new persisted state.
• drainPendingAdmissions without a deadline (only session disposal uses that form) skips stopping entries. With a deadline (removal and archive, failClosedAfterDrainTimeout), it waits for every entry as before.
• Disposal can start while a migration is still on its way to registering, which then fails. Each markStopping() therefore also wakes a disposal drain that is already waiting, and the drain re-checks its entries. Test: "lets session disposal finish once a migration it waits for becomes stopping" (backgroundProcessManager.test.ts). Without the wake it times out with Expected: "finished", Received: "waiting".

Why this rather than a disposal deadline (option a) or a process-group probe (option b)

• A plain deadline on the disposal drain would also stop waiting for admitted spawns that may still register. The existing cleanup doc forbids that: the spawn could register after disposal lifted its seal, with no cleanup left to stop it. The deadline would also add a timer and an arbitrary wait to every disposal.
• A stopping migration can never register. So disposal, which deletes nothing, has nothing to wait for. Marking those entries fixes exactly the regression 🤖 fix: keep a refused or failed migration pending until its command exits #5579 introduced, with no new timing. Disposal behaves as before for every other pending entry.
• A process-group probe (b) would need a probe per runtime, including remote runtimes, which this change does not. It also does not help removal, which must keep failing closed anyway.

Validation

• Test-first: "a migration whose exit is never confirmed blocks removal but not session disposal" in backgroundProcessesFormalRepro.test.ts. Its fake runtime rejects exitCode after the kill, so the exit is never confirmed. Without the fix, disposal is still waiting after 2 s:

  Expected: "finished"
  Received: "waiting"
  (fail) ... > a migration whose exit is never confirmed blocks removal but not session disposal
  

  With the fix, disposal finishes, a later beginMigration is admitted (the seal is released), and a removal's cleanup(ws, { failClosedAfterDrainTimeout: true }) is still waiting. The test helper's afterEach disposal cleanup no longer needs a special case for this runtime.

• Bun 1.3.12: the repro file (16 tests), bash*, backgroundProcessManager, workspaceService.archive/remove, serviceContainer and agentSession.disposeRace pass (459 tests). make static-check passes. One run hit an unrelated flake in a non-host spawn test. It passed alone 3/3 here and 2/2 on main, and it is filed as 🤖 flake: two backends' same-name non-host spawns got one record directory under load #5591.

• Formal: formal/background-processes models removal and archive only, not session disposal, and this PR changes no formal files. Removal and archive behaviour is unchanged.

Risks

Low. The change only affects session disposal while a stopping migration is pending. Disposal now returns while that command may still be stopping. Disposal never deleted anything, and the entry stays tracked for removal and archive.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high • Cost: $44.17

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-03T21:54:06.461790Z	450bb83	New commits
🔒 Security Review	✅ Completed 2026-10-03T21:55:06.120570Z	450bb83	New commits

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: eee83d782a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[ThomasK33]

Readiness record for head 450bb83:

• CI: all checks pass on this head (29 pass, 4 skipped). The first Codex Comments run saw a review thread that was still unresolved at the time. After I resolved it, I re-ran that job and it passed. Unresolved threads: 0.
• Local: make static-check passes. 459 targeted tests pass on Bun 1.3.12. One unrelated spawn-test flake is filed as 🤖 flake: two backends' same-name non-host spawns got one record directory under load #5591.
• Review budget: 5 of 6 assessments. Normal reviews: round 1 had 1 finding (a disposal drain could miss a later markStopping()), fixed with a test, and round 2 had 0. Security: 0 and 0. Findings strictly shrank.
• Final independent check (clean context, on exactly this head): "ready with tracked follow-ups". No blocker. Its follow-ups are tracked in 🤖 bug: removal stays refused until restart after a migration's exit is never confirmed #5594: a stale failClosedAfterDrainTimeout doc line, and a recovery path for removal after an exit that is never confirmed (fail-closed by design).
• Decision: ready. Merging with squash, pinned to this head.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high • Cost: $44.17