Skip to content

fix(onboarding): guard get_status so a daemon hiccup cannot freeze the wizard#77

Open
FourthWiz wants to merge 1 commit into
NeuroSkill-com:mainfrom
FourthWiz:fix/onboarding-get-status-guard
Open

fix(onboarding): guard get_status so a daemon hiccup cannot freeze the wizard#77
FourthWiz wants to merge 1 commit into
NeuroSkill-com:mainfrom
FourthWiz:fix/onboarding-get-status-guard

Conversation

@FourthWiz

Copy link
Copy Markdown

src/routes/onboarding/+page.svelte's onMount makes several daemon calls; get_status (line ~791) was the only one left unguarded — every other call in onMount is already wrapped in try/catch. When it throws, the callback unwinds before the status event listener, calibration profile load, tts_init, and the daemon event handler ever register — status stays frozen at its initial placeholder value forever, isConnected stays permanently false, and the wizard shows "Ready/Scanning" with grey electrodes that can never update, because nothing is listening for real device data anymore.

This is a structural first-run reachability issue, not a rare race: ensureDaemonCompatible() runs in the root layout on every app start, before any route mounts, and its .catch only toasts — it never invalidates the cache. On a fresh install with no auth token yet, that promise rejects and stays cached, so the onboarding wizard's own get_status call is guaranteed to throw the first time a user runs the app.

Changes

  • Wrap the get_status call in a bare try { ... } catch (e) { console.error(e); }. No new user-facing string (scoped deliberately — this repo's i18n gate is expensive to trigger for a 3-line fix).

Testing

No vitest host currently covers onboarding/+page.svelte; inventing one for a 3-line guard would exceed the fix's blast radius, so this is stated rather than papered over with a token test.

Related

Changelog fragment included: changes/unreleased/fix-onboarding-get-status-guard.md (Bugfixes).

…e wizard

The get_status daemon call in onMount was the only unguarded daemon call in
the onboarding wizard's initialization sequence. When it throws (e.g. no
auth token yet on a fresh install, since ensureDaemonCompatible's rejection
is cached in the root layout before the wizard even mounts), the callback
unwinds before the status event listener, calibration profile load, and TTS
init ever register — leaving the wizard permanently frozen with a
disconnected-looking device status and no way to proceed.

Wrap the call in try/catch (console.error only, no new user-facing string)
so the rest of onMount continues to run even when this one call fails.
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