Skip to content

feat: say the backend is starting instead of claiming it is broken - #7

Merged
ycli0536 merged 1 commit into
mainfrom
backend-startup-banner
Aug 31, 2026
Merged

feat: say the backend is starting instead of claiming it is broken#7
ycli0536 merged 1 commit into
mainfrom
backend-startup-banner

Conversation

@ycli0536

Copy link
Copy Markdown
Owner

The last piece of the startup plan (#4, #6). The packaged backend needs ~2s on a warm launch and ~20s on the first launch after an install — and during that window every API call failed with "could not reach the backend", telling users to go check on a backend that was doing exactly what it should.

What it does

  • Backend gains GET /api/health (two tests, including the CORS preflight).
  • A slim top banner polls it once a second until it answers: "Connecting to the CSEMInsight backend… (Ns)". Past 45s it adds the honest fallback: a first launch can take half a minute, and beyond that the backend at the shown address may genuinely have failed.

When it stays invisible

  • Demo mode — no backend exists, no polling at all.
  • Before the first probe answers — so a dev session with the backend already running never flashes it.
  • Once ready — polling stops for good; a backend dying later is reported by the failing call itself, which keeps this component a startup indicator rather than a health monitor.

Six tests cover: immediate-ready renders nothing, banner while down, clears on recovery, long-wait hint, demo-mode silence, and polling stops after ready.

Verification

  • Backend: health tests pass (suite was green at 382 before this branch).
  • Frontend: the 6 new tests pass; lint clean; bun run build clean.
  • Pre-existing flake, not from this PR: the full local frontend suite intermittently fails 3 TriangleModelWindow timeouts under parallel load. Verified on clean main (3 failed / 265 passed there too); they pass in isolation and CI has been green. Tracked as a separate task.

🤖 Generated with Claude Code

The packaged backend needs a couple of seconds on a warm launch and ~20s
on the first launch after an install. During that window every API call
failed with "could not reach the backend", which reads as broken, not
starting - the message told users to go check on a backend that was
doing exactly what it should.

The backend gains GET /api/health, and a slim top banner polls it once a
second until it answers: "Connecting to the CSEMInsight backend... (Ns)".
Past 45s it adds the honest explanation - a first launch can take half a
minute, and beyond that the backend at the shown address may genuinely
have failed. The banner never renders in demo mode (no backend exists),
before the first probe answers, or after the backend is up, so a dev
session with the backend already running never sees it. Polling stops
for good once ready; a backend dying later is reported by the failing
call itself.

Note: the local full-suite frontend run currently flakes on three
pre-existing TriangleModelWindow timeouts under parallel load (they fail
on clean main too, pass in isolation and in CI); tracked separately.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@ycli0536
ycli0536 merged commit 484a013 into main Aug 31, 2026
10 checks passed
@ycli0536
ycli0536 deleted the backend-startup-banner branch August 31, 2026 00:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant