Product
Platform/Access controls/Other
Describe the bug
fetchAuthToken (refresh.ts) uses a bare axios import instead of the app's apiRequest instance, so it loses the default Content-Type: application/json header. The backend only parses JSON, so Fastify's own 415 fires before the route's auth logic runs, and error-handler.ts has no branch for Fastify's native error class, masking it as a generic 500.
To Reproduce
- Log in, then fully reload the page (or open a protected URL in a new tab) while the session cookie is still valid.
- The
_authenticate route guard's own fetchAuthToken call hits the masked 500 and treats it as unauthenticated.
- User is bounced to
/login with an "Access Restricted" toast, despite having a valid session.
Expected behavior
A valid session cookie should survive a page reload. A content-type mismatch on /api/v1/auth/token should surface as 415, not an opaque 500 that the route guard can't distinguish from "not logged in".
Screenshots
No response
Deployment Type
Self-hosted
Additional context
Actual Behavior
Every reload/new-tab/deep-link into a protected route while fetchAuthToken's in-memory token is empty forces this call, and it always fails, kicking an authenticated user back to /login.
Environment
- Self-hosted,
v0.162.24, also present on master HEAD
Additional Information
Verified with a curl reproduction, the matching server-side stack trace by request ID, and a full trace of root.tsx/authenticate.tsx/refresh.ts/request.ts, confirmed identical between master and v0.162.24.
Proposed solution
In refresh.ts, use apiRequest instead of the bare axios import so the call gets the app's default JSON header. Separately, add a branch in the error handler for Fastify's native FastifyError so any future content-type mismatch surfaces its real status instead of a masked 500.
Product
Platform/Access controls/Other
Describe the bug
fetchAuthToken(refresh.ts) uses a bareaxiosimport instead of the app'sapiRequestinstance, so it loses the defaultContent-Type: application/jsonheader. The backend only parses JSON, so Fastify's own 415 fires before the route's auth logic runs, anderror-handler.tshas no branch for Fastify's native error class, masking it as a generic 500.To Reproduce
_authenticateroute guard's ownfetchAuthTokencall hits the masked 500 and treats it as unauthenticated./loginwith an "Access Restricted" toast, despite having a valid session.Expected behavior
A valid session cookie should survive a page reload. A content-type mismatch on
/api/v1/auth/tokenshould surface as 415, not an opaque 500 that the route guard can't distinguish from "not logged in".Screenshots
No response
Deployment Type
Self-hosted
Additional context
Actual Behavior
Every reload/new-tab/deep-link into a protected route while
fetchAuthToken's in-memory token is empty forces this call, and it always fails, kicking an authenticated user back to/login.Environment
v0.162.24, also present onmasterHEADAdditional Information
Verified with a
curlreproduction, the matching server-side stack trace by request ID, and a full trace ofroot.tsx/authenticate.tsx/refresh.ts/request.ts, confirmed identical betweenmasterandv0.162.24.Proposed solution
In
refresh.ts, useapiRequestinstead of the bareaxiosimport so the call gets the app's default JSON header. Separately, add a branch in the error handler for Fastify's nativeFastifyErrorso any future content-type mismatch surfaces its real status instead of a masked 500.