Hold boot splash until live shells load (no stale "running" flash)#38
Merged
Conversation
On (re)load the dashboard painted the server-injected initial model and lifted the
boot splash on the next microtask — before the live /api/shells fetch resolved. Since
a session's `running` flag is a point-in-time server snapshot ("tmux session exists"),
this flashed a stale "running" until the live load landed a moment later.
Gate the splash reveal on the first live loadShells() (.finally), so we only ever show
client-confirmed state. A 4s setTimeout safety net (plus the page's own 4s hard fallback)
guarantees the splash can never stick if the fetch hangs.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR adjusts the dashboard boot sequence so the boot splash stays visible until the first live shells load completes, preventing a brief flash of stale "running" state from the server-injected initial model during reload/refresh.
Changes:
- Remove the eager
queueMicrotask(markBooted)splash lift after initial render. - Lift the boot splash via
loadShells().finally(...)(plus a 4s timeout fallback) so the UI reveals after attempting the first live shells fetch. - Regenerate the served
public/events.jsto match thefrontend/events.tssource changes.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| frontend/events.ts | Gates booted class application on the first live loadShells() completion, with a timeout fallback. |
| public/events.js | Compiled output reflecting the updated boot-splash gating logic. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+491
to
+495
| // Hold the boot splash up until the first LIVE shell load confirms session state. The injected | ||
| // initial model is a point-in-time server snapshot (running = "tmux session exists"), so revealing | ||
| // it immediately flashes a stale "running" before the live fetch lands. Gating the reveal on | ||
| // loadShells() means we only ever show client-confirmed state. The timeout is a safety net so the | ||
| // splash can never stick if the fetch hangs (the page also keeps its own 4s hard fallback). |
Comment on lines
+538
to
+542
| // Hold the boot splash up until the first LIVE shell load confirms session state. The injected | ||
| // initial model is a point-in-time server snapshot (running = "tmux session exists"), so revealing | ||
| // it immediately flashes a stale "running" before the live fetch lands. Gating the reveal on | ||
| // loadShells() means we only ever show client-confirmed state. The timeout is a safety net so the | ||
| // splash can never stick if the fetch hangs (the page also keeps its own 4s hard fallback). |
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.
Problem
On (re)load, the dashboard paints the server-injected
initial-modeland lifts the boot splash on the next microtask — before the live/api/shellsfetch resolves. A session'srunningflag is a point-in-time server snapshot (running= "tmux session exists"), so the dashboard flashes a stale "running" until the live load lands a moment later. Refreshing showed "running" for things that weren't.Fix
Gate the splash reveal on the first live
loadShells()(.finally), so we only ever reveal client-confirmed state. A 4ssetTimeoutsafety net (plus the page's existing 4s hard fallback) guarantees the splash can't stick if the fetch hangs.frontend/events.ts(source) +public/events.js(compiled, served).Verification (real browser, against the running dashboard)
bootedis now added only vialoadShells().finally(liftBootSplash)or the 4s fallback; the eagerqueueMicrotask(markBooted)is gone.tsc --noEmitclean.🤖 Generated with Claude Code