Repository navigation
fix(#283): auto-heal panes stuck at 'loading transcript' on startup/resume - #297
Closed
Juliusolsson05 wants to merge 1 commit into
Closed
Juliusolsson05 wants to merge 1 commit into
Juliusolsson05 wants to merge 1 commit into
Conversation
…esume The committed-transcript channel can fail to attach on resume/rehydrate: the load's terminal 'ready'/'error' write is discarded when its runtime key is dropped or re-keyed mid-flight (the RESOLVE-DROPPED / ERROR-DROPPED paths from the #284 instrumentation), OR the pane is marked 'loading' by rehydrate but no loader is ever kicked. Either way the pane spins forever — or paints an empty "waiting for…" feed with the user's prompts missing — until a manual reload re-runs the loader under a now-stable id. This automates that manual reload: - Track in-flight initial-history loads in a module-level Set (added before the 'loading' write, cleared in a finally on every exit incl. dropped-write). - reconcileStuckTranscriptLoads(): scan current runtimes for panes that are (a) stuck at 'loading', (b) not currently loading, (c) backed by a durable provider session, and re-drive the load for each. Conservative — only touches already-broken panes, no-op otherwise. - useBootstrap schedules three detached sweeps (1.5s/4s/8s after rehydrate) so a slow first load settles before we treat a pane as stuck, and panes that only become stuck after their dropped load resolves still get caught. Covers both failure modes (dropped-write race AND marked-loading-never-loaded). Renderer-only; typechecks clean. The #284 [xcript-diag] logs are left in place so the heal can be verified against them, then removed in a cleanup once confirmed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Owner
Author
|
Superseded — applying the auto-heal directly to the main working tree for live testing instead of via PR, per maintainer request. Same change (broadened to also re-drive empty-feed panes, not just the spinner). |
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.
The bug (plain version)
On startup/resume, the saved-transcript channel sometimes fails to attach to a pane while the live channel works fine. The pane then either spins forever on "loading transcript" or paints an empty "waiting for Claude" feed with the user's prompts missing — until a manual reload fixes it. Confirmed from feed-debug: one restored pane logged 22 MB of live activity but rendered a single "waiting for Claude" row.
Two underlying causes (both from the #284 instrumentation + rehydrate analysis):
ready/errorwrite is discarded when its runtime key is dropped/re-keyed mid-flight (RESOLVE-DROPPED/ERROR-DROPPED).loadingbut the loader is never kicked.Either way: pane stuck at
loadingwith nothing driving it. A manual reload re-runs the loader under a now-stable id and fixes it.The fix
Automate that manual reload:
loadingwrite, cleared in afinallyon every exit including the dropped-write paths).reconcileStuckTranscriptLoads()— sweep current runtimes for panes that are (a) stuckloading, (b) not currently loading, (c) backed by a durable provider session, and re-drive the load for each. Conservative: only touches already-broken panes, no-op otherwise.useBootstrapschedules three detached sweeps (1.5s / 4s / 8s after rehydrate) so a slow first load settles before a pane is judged stuck, and panes that only go stuck after their dropped load resolves still get caught.Covers both failure modes. Renderer-only, typechecks clean.
Run the app, restart it with several Claude/Codex panes open, and confirm panes reach their transcript without a manual reload. Watch the console: you'll see the existing
[xcript-diag] RESOLVE-DROPPED …followed by[xcript-heal #283] re-drove N stuck pane(s) …and thenready-set— that sequence is the heal working.The #284
[xcript-diag]logs are intentionally left in for this validation; remove them in a follow-up cleanup once confirmed.🤖 Generated with Claude Code