Skip to content

fix(providers): reconnecting no longer cancels a runtime install - #604

Merged
yaacovcorcos merged 3 commits into
mainfrom
claude/runtime-install-reconnect-20261019
Oct 19, 2026
Merged

yaacovcorcos merged 3 commits into
mainfrom
claude/runtime-install-reconnect-20261019

Conversation

@yaacovcorcos

Copy link
Copy Markdown
Contributor

What Changed

  • Reconnecting no longer cancels a runtime install. ProviderRuntimeManager.start did 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 pattern ProviderConnectionManager uses for sign-in since fix(antigravity): reliable Google sign-in on Windows; app-owned sign-in page opening #595. The old body is unchanged, renamed startup.
  • A stalled first runtime-state read can't hold the provider busy. Before the operation is published, nothing can cancel it. That read now gives up after two minutes with "Scient could not read the provider runtime state in time. Try again." and releases the reservation.

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.resolveCommandPath running 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

  • This PR is small and focused
  • I explained what changed and why
  • I included before/after screenshots for any UI changes
  • I included a video for animation/interaction changes

Tests: ProviderRuntimeManager.test.ts 32/32.

  • New: the caller disconnects during planning, and the change still runs to succeeded and releases its reservation.
  • New: a stalled first runtime-state read releases the reservation after two minutes.
  • New: an interrupted initial publication releases its own reservation with the manager still open.
  • Three tests that used caller interruption to reach startup cleanup now use manager shutdown, the only thing that can still interrupt a startup.
  • Each new test fails with its fix removed.
  • ProviderConnectionManager.test.ts 52/52 and ManagedRuntimeSystemSwitch.test.ts 28/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

Yaacov and others added 3 commits October 19, 2026 17:35
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>
@github-actions github-actions Bot added size:M vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. labels Oct 19, 2026
@github-actions

Copy link
Copy Markdown
Contributor

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider Metric Main baseline This PR Impact PR ceiling
Codex Total thread wire 5.6 KiB 5.6 KiB 0 B (0.0%) 6.8 KiB ✅
Codex Thread snapshot wire 4.3 KiB 4.3 KiB 0 B (0.0%) 4.9 KiB ✅
Codex Live turn WebSocket wire 1.3 KiB 1.3 KiB 0 B (0.0%) 2.0 KiB ✅
Codex Live turn WebSocket decoded 26.2 KiB 26.2 KiB 0 B (0.0%) 29.3 KiB ✅
Codex Live turn messages 2 2 0 (0.0%) 8 ✅
Claude Total thread wire 5.6 KiB 5.6 KiB 0 B (0.0%) 6.8 KiB ✅
Claude Thread snapshot wire 4.3 KiB 4.3 KiB 0 B (0.0%) 4.9 KiB ✅
Claude Live turn WebSocket wire 1.3 KiB 1.3 KiB 0 B (0.0%) 2.0 KiB ✅
Claude Live turn WebSocket decoded 26.6 KiB 26.6 KiB 0 B (0.0%) 29.3 KiB ✅
Claude Live turn messages 2 2 0 (0.0%) 8 ✅

Baseline: 15893fa · PR result: 46bc6a8 · Source CI: success

Scenario and decoded snapshot size

10 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.
Full compact HTTP snapshot with live cursor.

  • Codex decoded thread snapshot: 133.1 KiB
  • Claude decoded thread snapshot: 133.4 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

@yaacovcorcos
yaacovcorcos added this pull request to the merge queue Oct 19, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Oct 19, 2026
@yaacovcorcos
yaacovcorcos added this pull request to the merge queue Oct 19, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Oct 19, 2026
@yaacovcorcos
yaacovcorcos added this pull request to the merge queue Oct 19, 2026
Merged via the queue into main with commit 7966aa7 Oct 19, 2026
36 checks passed
@yaacovcorcos
yaacovcorcos deleted the claude/runtime-install-reconnect-20261019 branch October 19, 2026 18:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size:M vouch:trusted PR author is trusted by repo permissions or the VOUCHED list.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant