fix: prevent blank screen after desktop auth

[Soulter]

Summary

• persist the passwordless desktop session, then perform one guarded reload before the dashboard initializes
• prevent the desktop bridge from changing the auth hash before Vue has mounted
• preserve automatic token reacquisition after the dashboard is running
• add regression coverage for the initial reload, loop prevention, and later token recovery

Root cause

The desktop authentication bridge could finish while Vue Router was still resolving its initial navigation. Updating the auth hash during that window could leave the WKWebView dashboard with an empty #app node. A manual reload worked because the token had already been persisted by then.

User impact

The dashboard should no longer remain on a white screen during the first launch after passwordless authentication. The bridge reloads at most once per WebView session and starts the dashboard with a stable token.

Validation

• node --test scripts/prepare-resources/bridge-bootstrap-updater-contract.test.mjs — 7 passed
• node --check src-tauri/src/bridge_bootstrap.js
• cargo fmt --manifest-path src-tauri/Cargo.toml -- --check
• cargo test --manifest-path src-tauri/Cargo.toml --quiet — 162 passed
• git diff --check

Summary by Sourcery

Guard desktop passwordless authentication to avoid blank initial loads in the desktop dashboard while preserving automatic token refresh.

Bug Fixes:

• Ensure the dashboard performs at most one guarded reload after desktop passwordless authentication to prevent a blank screen during initial launch.
• Prevent the desktop bridge from changing the auth hash before the Vue app has mounted, only redirecting to the welcome route once the app is initialized.

Enhancements:

• Track desktop auth bootstrap reload state in session storage to stabilize the initial WebView session while maintaining regular token refresh behavior.

Tests:

• Extend the bridge bootstrap contract tests to cover initial reload behavior, reload loop prevention, and subsequent token reacquisition across WebView sessions.

[sourcery-ai]

Hey - I've left some high level feedback:

• The new sharedState object in runBootstrap is growing multiple responsibilities (local/session storage, navigation, app mount state); consider encapsulating these into a small mock runtime/helper to keep the test harness easier to extend and reason about.
• In shouldReloadAfterDesktopAuthBootstrap, you unconditionally set the session storage flag when it doesn't exist yet; if a reload is blocked by the environment (e.g., in tests or non-WKWebView contexts), you might want to consider only flipping the flag after reload is actually invoked to avoid silently disabling future reload attempts.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The new `sharedState` object in `runBootstrap` is growing multiple responsibilities (local/session storage, navigation, app mount state); consider encapsulating these into a small mock runtime/helper to keep the test harness easier to extend and reason about.
- In `shouldReloadAfterDesktopAuthBootstrap`, you unconditionally set the session storage flag when it doesn't exist yet; if a reload is blocked by the environment (e.g., in tests or non-WKWebView contexts), you might want to consider only flipping the flag after `reload` is actually invoked to avoid silently disabling future reload attempts.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}