Repository navigation
fix(providers): reconnecting no longer cancels a runtime install - #604
Merged
Merged
Conversation
ProviderRuntimeManager.start did everything before handing off to its supervisor in the request's fiber: planning (which resolves executables and took 34 s on a loaded machine), the plan check, the lifecycle reservation, the summary probe and the "preparing" publication. When the window's WebSocket dropped and reconnected meanwhile, the request was interrupted and the install never started. Startup now runs in the manager's scope, as sign-in startup already does in ProviderConnectionManager; the request only joins it. A caller that stays connected still gets the same errors and providers; a caller that leaves no longer stops the change. Cancel works as before once the operation is visible, and manager shutdown still interrupts a startup in flight and runs its cleanup. The interrupted-startup tests now drive that cleanup through shutdown. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review follow-up. With the startup owned by the manager, a stalled read of the runtime state after the reservation held the provider busy with nothing published that Cancel could reach. The read now gives up after two minutes and releases the reservation. A test also isolates the initial publication's own cleanup again, which closing the manager could mask. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
Thread transfer impact✅ Thread transfer remains within every enforced ceiling.
Baseline: Scenario and decoded snapshot size10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.
Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed. |
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Oct 19, 2026
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Oct 19, 2026
2 of 4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What Changed
ProviderRuntimeManager.startdid all of its startup in the WebSocket request's fiber: planning (which includes a PATH lookup), the plan-revision check, the lifecycle reservation, the first runtime-state read and the "preparing" publication. Only after that did it hand off to a background supervisor. The whole startup now runs in a manager-owned fiber (Effect.forkIn(managerScope)), and the request just joins it. A reload or disconnect only detaches the request; cancel and manager shutdown still end it. This is the same patternProviderConnectionManageruses for sign-in since fix(antigravity): reliable Google sign-in on Windows; app-owned sign-in page opening #595. The old body is unchanged, renamedstartup.Why
Seen in the dev app on Windows: installing the Scient Agent runtime from Settings was cancelled. The trace shows
server.startProviderRuntime→ProviderRuntimeManager.plan→shell.resolveCommandPathrunning for 34 s on a heavily loaded machine. The window's connection dropped meanwhile, and when it reconnected at 15:37:37 the request fiber was interrupted, taking the install with it.Both files are Scient-owned; no upstream-owned code changes.
Documentation Impact
Documentation impact: Updated — docs/internals/provider-lifecycle.md
Checklist
Tests:
ProviderRuntimeManager.test.ts32/32.succeededand releases its reservation.ProviderConnectionManager.test.ts52/52 andManagedRuntimeSystemSwitch.test.ts28/28 on the first commit; server typecheck clean.Review: Codex, two rounds. Round 1 found no problem with the fork/join interruption semantics or the handoff race. It asked for the bounded first read and the isolated publication-cleanup test. Round 2 approved with no findings.
Not verified: a real WebSocket drop during an install in the desktop app; the behaviour is covered at the manager level.
🤖 Generated with Claude Code