Session expires after one hour without warning, and in-progress instrument data is lost #1535

Activity

1. gdevenyi

   added

   BugType: existing behavior is wrongType: existing behavior is wrong

   on Sep 11, 2026
2. gdevenyi

   changed the title [-]Session expires after one hour without warning; a submission after expiry fails with a generic 401[/-] [+]Session expires after one hour without warning, and in-progress instrument data is lost[/+] on Sep 11, 2026
3. joshunrau

   added

   Priority: HighSignificant or frequently hit user impact; target the next release or twoSignificant or frequently hit user impact; target the next release or two

   Difficulty: HighMore than a day, or touches several workspacesMore than a day, or touches several workspaces

   Area: Webapps/web (clinician-facing React SPA)apps/web (clinician-facing React SPA)

   Needs DecisionWell-defined, but blocked on a maintainer decision about direction or designWell-defined, but blocked on a maintainer decision about direction or design

   on Sep 27, 2026
4. joshunrau commented on Oct 26, 2026

   

   joshunrau

   on Oct 26, 2026

   Collaborator

   More actions

   Partly fixed on main (d86740e). 7fd9025 (#1538) gave the bundle query staleTime: Infinity, so a non-admin who comes back to the tab keeps the form. An admin still loses it, and the submit case is unchanged for everyone (void onSubmit is now at FormContent.tsx:61, expiresIn: '1h' at auth.service.ts:84).

   Why admins still lose the form

   For a user who can manage all, useSwitchableGroups runs groupsQueryOptions() through a plain useQuery (apps/web/src/hooks/useSwitchableGroups.ts:16), and that query sets no staleTime (apps/web/src/hooks/useGroupsQuery.ts:7-15). Layout, Navbar and Sidebar all mount it through useIsGroupSwitcherVisible. The refetch on focus gets the 401 and throws from the _app layout, so the error page replaces the whole layout, render page included. The #1538 e2e test runs as the default GROUP_MANAGER and does not catch this.

   Corrections to the approaches

   • Approach 1. Since 82ed5d4, the render page's NavigationBlocker enables beforeunload on the content step (packages/react-core/src/components/InstrumentRenderer/InstrumentRendererContainer.tsx:107-116, apps/web/src/components/NavigationBlocker.tsx:9). A window.location.assign from the interceptor raises the browser's "Leave site?" prompt. If the user cancels, they stay on a page where every request returns 401.
   • The login request does not set meta.disableDefaultAuth (apps/web/src/routes/auth/login.tsx:19-21). Its validateStatus accepts 401, so the error handler never sees it. Key the interceptor on whether the request carried a bearer token.
   • Approach 2 cannot reuse the store's login(). It restores preferredGroupId only if the token's groups contain it (apps/web/src/store/slices/auth.slice.ts:32-45), so an admin working in a group they are not a member of falls back to groups[0]. currentGroupId is part of the bundle query key, so the bundle refetches, render/$id.tsx:103-105 renders <Spinner />, and the renderer unmounts with the data.

   Recommendation

   Hold 401s in the axios layer and replay them after the user signs in again, in the same shape as the transient retry (apps/web/src/services/axios.ts:140-161).

   1. Response interceptor. When a request that carried a token gets a 401, set isSessionExpired in the store and wait (useAppStore.subscribe) until accessToken differs from the token it was sent with. Then return axios(requestConfig); the request interceptor (axios.ts:117-119) attaches the new token. Concurrent 401s share one wait and show no toast. Replaying a write is safe, unlike in the transient case: on an authenticated route the 401 comes from the global JwtAuthGuard (apps/api/src/auth/auth.module.ts:30-31) before the handler runs, and only the public login handler throws one.
   2. reauthenticate(accessToken) in auth.slice.ts. It replaces accessToken and currentUser and keeps currentSession and the current group id. Take the group object from the new token when its id is there, so changed group settings apply; keep the old object otherwise.
   3. A SessionExpiredDialog in __root.tsx, beside ConnectivityBanner and outside the _app error boundary. It asks only for the password, with the username fixed to currentUser.username, so no other user can take over currentSession, and it offers Sign out. Move loginRequest into src/hooks/ with meta.disableDefaultAuth: true. If the account is now archived, disabled or mustResetPassword, sign out. Strings go through t() with en, es and fr.

   A held query neither errors nor unmounts, so this fixes both cases with throwOnError: true and the apps/web/AGENTS.md rule unchanged.

   Separately, in its own PR, I would change the query default to (_error, query) => query.state.data === undefined. useSuspenseQuery already overrides the client default with exactly that function (defaultThrowOnError, @tanstack/react-query 5.104.0), so true only reaches plain useQuery. For a non-admin today, a failed refetch leaves /datahub/subjects on screen with a toast but replaces /dashboard (useSummaryQuery, useInstrumentInfoQuery) with the error page. Update the AGENTS.md bullet and services/__tests__/react-query.test.ts with it, and leave mutations at true.

   Open question

   A warning before expiry, or approach 3, only helps if an open tab may renew its token without a password. Is one hour an absolute cap or an idle timeout? If idle, an API route that re-signs a still-valid token while the user is active is enough, and tokens stay in memory.

   Tests

   • services/__tests__/axios.test.ts: a held 401 is replayed with the new token; concurrent 401s share one wait; a request without a token is not held; a held 401 shows no toast.
   • store/slices/__tests__/auth.slice.test.ts: reauthenticate keeps currentSession and the current group.
   • A unit test for the dialog, and routes/auth/__tests__/login.test.tsx after the move.
   • A new testing/src/specs/session-expiry.spec.ts. After the page loads, page.route('**/v1/**') returns 401 only when Authorization carries the injected token (window.__PLAYWRIGHT_ACCESS_TOKEN__), so the old token "expires" and the new one works. roleAccount exposes no password, so seed the user with api.createUser() and pass its credentials to authenticateAs; for ADMIN, use ADMIN.password.
     • Refetch: on /dashboard, and on the render page as ADMIN, hide and show the tab as the Instrument bundle refetches on window focus although the bundle for an ID does not change #1538 test does (setTabVisibility). The dialog shows, error-page does not, and the entered values survive sign-in.
     • Submit: submit, sign in, then the summary shows and the record is saved.

   #1534 changes what the token carries; whichever lands second adjusts reauthenticate.

   _{Triage note written with Claude Code. Code references point at main @ d86740e.}