Skip to content

Don't let a failed settings fetch block auth restore on reload - #6

Open
JustSamuel wants to merge 1 commit into
developfrom
fix/852-beforeload-auth-reload
Open

Don't let a failed settings fetch block auth restore on reload#6
JustSamuel wants to merge 1 commit into
developfrom
fix/852-beforeload-auth-reload

Conversation

@JustSamuel

Copy link
Copy Markdown
Collaborator

Ported from GEWIS/sudosos-frontend#853.

No changes needed during the port beyond the directory prefix (frontend/) -- patch applied cleanly via git am, and frontend:build/frontend:lint both pass.

beforeLoad() returned early if settingsStore.fetchKeys() threw, which
skipped populateStoresFromToken() for the rest of that page load. On
any fresh page load (hard reload or deep link) that meant a logged-in
user's auth store never got repopulated from their stored JWT, so the
router guard treated them as unauthenticated and sent them back to
login even with a valid token.

Locally this fires on every hard reload once STRIPE_PUBLIC_KEY is
unset, since /v1/stripe/public then 401s, but the same early return
would fire in production too if that settings fetch ever failed for
an unrelated reason.

Catch the fetchKeys() failure inline instead of returning early, so
populateStoresFromToken() and the terms-of-service fetch always run
regardless of whether the settings fetch succeeded. setupWebSocket()
gets its own try/catch for the same reason.

Fixes #852

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR updates the dashboard’s startup beforeLoad sequence so that a failure while fetching public settings keys no longer prevents authentication restoration when the app is reloaded. This aligns the dashboard’s behavior with the ported change from the upstream frontend repository.

Changes:

  • Decouples settingsStore.fetchKeys() error handling from the WebSocket setup block so settings failures no longer short-circuit initialization.
  • Ensures populateStoresFromToken(apiService) still runs even if fetching settings keys fails, allowing auth restoration to proceed on reload.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

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.

3 participants