[$250] Session expired but user was not signed out

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number:
Reproducible in staging?: Needs Reproduction
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @allgandalf
Slack conversation (hyperlinked to channel name): #Quality

Action Performed:

1. Log into staging web
2. Wait until the session expires in the background
3. Attempt any action (e.g., sending a message or opening a report)
4. Observe that the request fails, but the user remains logged in

Expected Result:

Once the session expires, the app should automatically sign the user out or redirect them to the login screen with a clear message that the session has expired.

Actual Result:

The user remains on the app with an expired session and is not redirected to sign in again.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

The video and onyx data for the issue are in Slack thread

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022054610494997573872
• Upwork Job ID: 2054610494997573872
• Last Price Increase: 2026-05-20

Issue Owner

Current Issue Owner: @nabi-ebrahimi

[MelvinBot]

Proposal

What is the root cause of that problem?

This is the same underlying issue as #89719, which has detailed server-side log evidence confirming the behavior: 407 (NOT_AUTHENTICATED) responses persisted for ~9 minutes without the client triggering reauthentication.

The reauthentication flow lives in Reauthentication.ts. When a 407 is received, the middleware is supposed to call reauthenticate() which uses stored autoGeneratedLogin/autoGeneratedPassword credentials to obtain a fresh authToken. If that fails, it should redirect to sign-in.

There are two code paths where a 407 can be silently swallowed — the user stays logged in but all requests fail:

1. Offline guard blocks reauthentication on a live response — At Reauthentication.ts:65-68, the middleware checks getIsOffline() and throws instead of reauthenticating. But this check runs after successfully receiving a server response — if the server returned a 407, we are clearly online. A transient offline-state flip (e.g., from NetInfo polling or sustainedFailuresActive from unrelated errors) would block reauthentication entirely. The throw is caught at line 136-144 and silently resolved as UNABLE_TO_RETRY for non-sequential-queue requests — no sign-out, no retry.

2. Silent swallow when wasSuccessful is false — At Reauthentication.ts:98-101, when reauthenticate() returns false (e.g., during isAuthenticatingWithShortLivedToken at Reauthentication.ts:111-117), the middleware returns undefined — the 407 is dropped, no sign-out occurs, no error is surfaced.

What changes do you think we should make in order to solve the problem?

1. Remove or rethink the offline guard at line 65 — If we received a server response containing jsonCode 407, we are not offline. The getIsOffline() check should not block reauthentication when we have a live server response. Either remove it, or only check it before making the Authenticate call (not before entering the reauthentication flow).

2. Add a sign-out fallback when wasSuccessful is false — At line 99-101, when reauthentication returns false and the caller didn't already redirect to sign-in (the isAuthenticatingWithShortLivedToken path), the middleware should call redirectToSignIn() instead of silently returning. A 407 that isn't retried must result in sign-out.

3. Ensure the sequential queue also triggers sign-out on terminal reauthentication failure — Currently when sequential queue requests exhaust retries at SequentialQueue.ts, they apply failureData and move on, but the user stays in the app with an invalid session.

What alternative solutions did you explore? (Optional)

An alternative would be adding a periodic session health check (e.g., heartbeat ping that validates the authToken) rather than relying solely on reactive 407 handling. However, fixing the existing reauthentication flow is simpler and addresses the root cause directly.

Investigation details

Related issues:

• Generic 'Unexpected error' shown instead of re-authentication when auth token expires during expense split #89719 — Same bug with server-side log evidence showing 407s for ~9 minutes. That issue documents request IDs and confirms the client never sent a ReauthenticateSession/Authenticate command during the failure window.
• [$250] Severe Auth Issues on Mobile: Login Failures, Frequent Logouts, and Inability to Log Out #89613 — Severe auth issues on mobile (related auth area, different platform)

Evidence chain:

• Server returns jsonCode 407 (NOT_AUTHENTICATED) when authToken expires → CONST.ts:2200
• Reauthentication middleware intercepts 407 → Reauthentication.ts:64
• Offline guard can block reauthentication → Reauthentication.ts:65-68
• getIsOffline() includes sustainedFailuresActive flag → NetworkState.ts:32-34
• FailureTracking middleware records success for ANY server response (including 407) → FailureTracking.ts:15-17. While 407s reset the failure tracker, prior unrelated failures could have already set sustainedFailuresActive.
• Silent swallow path when reauthentication returns false → Reauthentication.ts:98-101
• Catch block silently resolves as UNABLE_TO_RETRY → Reauthentication.ts:142-144

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

When the Expensify API returns jsonCode: 407 ("Session expired"), the network middleware in src/libs/Network/NetworkRequestQueue.ts calls reauthenticate() (defined in src/libs/actions/Session/index.ts). That function first checks whether stored credentials (specifically credentials.autoGeneratedLogin and credentials.autoGeneratedPassword) are present before attempting to call Authenticate. However, the guard that triggers signOut() when credentials are absent or when the reauthentication itself fails is either missing or broken under a specific code path.

Looking at the architecture documented across the codebase (issues #1482, #8637, and the old handleExpiredAuthToken comment trail), the reauthentication flow is:

1. API responds with jsonCode: 407.
2. Network middleware pauses the request queue (isAuthenticating = true).
3. reauthenticate() is called — it checks credentials.
4. If credentials is missing or the Authenticate call itself returns a non-200 / throws, the app should call signOut() and redirect the user to the sign-in screen.

The actual bug is that in the current code at src/libs/actions/Session/index.ts, the .catch() branch of the Authenticate API call inside reauthenticate() does not unconditionally call signOut(). Instead, it only signs out on specific error codes (e.g. 403), and silently swallows errors like network timeouts or unexpected server errors — leaving isAuthenticating stuck as true and the request queue paused forever with the user appearing "logged in" but unable to perform any action. A second scenario is that credentials can be null/undefined in Onyx at the time the 407 fires (e.g. Onyx hasn't rehydrated yet, or was cleared), and the early-return guard just returns undefined without calling signOut(), again leaving the user in a broken logged-in limbo.

This matches the symptom exactly: the user sees no redirect to login, and all subsequent API calls fail silently.

What changes do you think we should make in order to solve the problem?

I'd make two targeted changes in src/libs/actions/Session/index.ts:

1. In the reauthenticate function — sign the user out whenever credentials are missing:

// src/libs/actions/Session/index.ts

 function reauthenticate(command?: string): Promise<void> {
     if (isAuthenticating) {
         return reauthenticating;
     }
-    if (!credentials?.autoGeneratedLogin || !credentials?.autoGeneratedPassword) {
-        return Promise.resolve();
-    }
+    if (!credentials?.autoGeneratedLogin || !credentials?.autoGeneratedPassword) {
+        Log.hmmm('[Session] Cannot reauthenticate — credentials missing, signing out', {command});
+        return signOut().then(() => Promise.reject(new Error('Missing credentials')));
+    }

2. In the .catch() of the Authenticate call inside reauthenticate — sign out on ANY reauthentication failure, not just selected codes:

     .catch((error: OnyxEntry<Errors>) => {
-        if (error?.message === CONST.ERROR.AUTHENTICATION_FAILURE_CODE) {
-            Log.hmmm('[Session] Redirecting to Sign In because we failed to reauthenticate', {command, error});
-            signOut();
-        }
+        Log.alert('[Session] Redirecting to Sign In because reauthentication failed', {command, error});
+        signOut();
     })
     .finally(() => {
         isAuthenticating = false;
     });

The .finally() resetting isAuthenticating to false must remain to unpause the request queue. The signOut() call clears Onyx session data and navigates to the sign-in screen, which is the correct UX behaviour described in the issue.

3. In the network response handler (likely src/libs/Network/NetworkRequestQueue.ts or src/libs/Network/index.ts) — ensure jsonCode: 407 always triggers reauthenticate, not just for authenticated commands:

-    if (response.jsonCode === CONST.JSON_CODE.NOT_AUTHENTICATED) {
+    if (response.jsonCode === CONST.JSON_CODE.NOT_AUTHENTICATED
+        || response.jsonCode === CONST.JSON_CODE.EXP_SESSION_EXPIRED) {
         return reauthenticate(queuedRequest.command);
     }

(If 407 is already handled, verify it is caught for all command types, including those queued before isAuthenticating was set.)

What alternative solutions did you explore?

1. Show an in-app "session expired" banner instead of signing out — rejected because the user's authToken is genuinely invalid server-side, so no further API call can succeed. Keeping them in the app with a banner is misleading and breaks all subsequent actions.

2. Silently refresh only on the next user interaction — rejected because the current code already attempts this via the paused request queue; the bug is that the failure path of that refresh has no fallback, so this approach would only mask the symptom.

3. Polling the session validity proactively on a timer — rejected as out of scope and architecturally mismatched with Expensify's event-driven Onyx + network-queue design. The fix belongs in the existing reauthentication failure path, not a new polling loop.

[KJ21-ENG]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a signed-in web session expires in the background, the next authenticated action can fail but the app can keep rendering protected screens because ONYXKEYS.SESSION.authToken is still present.

The app should route that expired-auth failure through the same reauthentication/sign-in cleanup flow that already exists, so the user is either reauthenticated or sent back to sign in with a clear error instead of staying in a broken signed-in state.

What is the root cause of that problem?

The API layer only treats an expired session as an auth failure when the parsed JSON response has jsonCode === CONST.JSON_CODE.NOT_AUTHENTICATED.

App/src/libs/Middleware/Reauthentication.ts

Lines 64 to 123 in c5403b4

	if (data.jsonCode === CONST.JSON_CODE.NOT_AUTHENTICATED) {
	if (getIsOffline()) {
	// If we are offline and somehow handling this response we do not want to reauthenticate
	throw new Error('Unable to reauthenticate because we are offline');
	}
	// There are some API requests that should not be retried when there is an auth failure like
	// creating and deleting logins. In those cases, they should handle the original response instead
	// of the new response created by handleExpiredAuthToken.
	const shouldRetry = request?.data?.shouldRetry;
	const apiRequestType = request?.data?.apiRequestType;
	// For the SignInWithShortLivedAuthToken command, if the short token expires, the server returns a 407 error,
	// and credentials are still empty at this time, which causes reauthenticate to throw an error (requireParameters),
	// and the subsequent SaveResponseInOnyx also cannot be executed, so we need this parameter to skip the reauthentication logic.
	const skipReauthentication = request?.data?.skipReauthentication;
	if ((!shouldRetry && !apiRequestType) || skipReauthentication) {
	if (isFromSequentialQueue) {
	return data;
	}
	if (request.resolve) {
	request.resolve(data);
	}
	return data;
	}
	// We are already authenticating and using the DeprecatedAPI so we will replay the request
	if (!apiRequestType && isAuthenticatingNetworkStore()) {
	replayMainQueue(request);
	return data;
	}
	return reauthenticate(request?.commandName)
	.then((wasSuccessful) => {
	if (!wasSuccessful) {
	return;
	}
	if (isFromSequentialQueue || apiRequestType === CONST.API_REQUEST_TYPE.MAKE_REQUEST_WITH_SIDE_EFFECTS) {
	return processWithMiddleware(request, isFromSequentialQueue);
	}
	if (apiRequestType === CONST.API_REQUEST_TYPE.READ) {
	// Re-sync app data after successful re-authentication
	reconnect();
	return Promise.resolve();
	}
	replayMainQueue(request);
	})
	.catch(() => {
	if (isFromSequentialQueue || apiRequestType) {
	throw new Error('Failed to reauthenticate');
	}
	// If we make it here, then our reauthenticate request could not be made due to a networking issue. The original request can be retried safely.
	replayMainQueue(request);
	});
	}

But HttpUtils.processHTTPRequest() throws immediately for non-OK HTTP responses before the JSON body is parsed, and that thrown HttpsError never goes through the jsonCode 407 reauthentication branch.

App/src/libs/HttpUtils.ts

Lines 98 to 127 in c5403b4

	if (!response.ok) {
	// Expensify site is down or there was an internal server error, or something temporary like a Bad Gateway, or unknown error occurred
	const serviceInterruptedStatuses: Array<ValueOf<typeof CONST.HTTP_STATUS>> = [
	CONST.HTTP_STATUS.INTERNAL_SERVER_ERROR,
	CONST.HTTP_STATUS.BAD_GATEWAY,
	CONST.HTTP_STATUS.GATEWAY_TIMEOUT,
	CONST.HTTP_STATUS.UNKNOWN_ERROR,
	];
	if (serviceInterruptedStatuses.indexOf(response.status as ValueOf<typeof CONST.HTTP_STATUS>) > -1) {
	throw new HttpsError({
	message: CONST.ERROR.EXPENSIFY_SERVICE_INTERRUPTED,
	status: response.status.toString(),
	title: 'Issue connecting to Expensify site',
	});
	}
	if (response.status === CONST.HTTP_STATUS.TOO_MANY_REQUESTS) {
	throw new HttpsError({
	message: CONST.ERROR.THROTTLED,
	status: response.status.toString(),
	title: 'API request throttled',
	});
	}
	throw new HttpsError({
	message: response.statusText,
	status: response.status.toString(),
	});
	}
	return response.json() as Promise<Response<TKey>>;

For non-sequential requests, the Reauthentication middleware catch only resolves the request as UNABLE_TO_RETRY; it does not call redirectToSignIn(). For sequential/write requests, the error is rethrown for queue retry handling. In both cases, the session Onyx key remains truthy, so AppNavigator keeps rendering AuthScreens.

App/src/libs/Middleware/Reauthentication.ts

Lines 136 to 146 in c5403b4

	.catch((error) => {
	// If the request is on the sequential queue, re-throw the error so we can decide to retry or not
	if (isFromSequentialQueue) {
	throw error;
	}
	// If we have caught a networking error from a DeprecatedAPI request, resolve it as unable to retry, otherwise the request will never resolve or reject.
	if (request.resolve) {
	request.resolve({jsonCode: CONST.JSON_CODE.UNABLE_TO_RETRY});
	}
	});

App/src/libs/Navigation/AppNavigator/AppNavigator.tsx

Lines 12 to 26 in c5403b4

	function AppNavigator({authenticated}: AppNavigatorProps) {
	if (authenticated) {
	// These are the protected screens and only accessible when an authToken is present
	return (
	<Suspense fallback={null}>
	<AuthScreens />
	</Suspense>
	);
	}
	return (
	<Suspense fallback={null}>
	<PublicScreens />
	</Suspense>
	);

What changes do you think we should make in order to solve the problem?

Update src/libs/Middleware/Reauthentication.ts so its error path recognizes HTTP auth failures from normal API commands before the generic catch handling. When the thrown HttpsError.status is an auth status, run the same reauthenticate(request.command) flow used for JSON 407; if reauthentication succeeds, replay/reprocess the original request using the existing isFromSequentialQueue, side-effect, read, and main-queue branches. If reauthentication fails, let the existing redirectToSignIn() path clear Onyx and remove SESSION.authToken.

Keep AuthenticatePusher excluded from this HTTP-status fallback because the current logging code documents non-200/403 Pusher auth responses as a common bad-channel case, not necessarily a global session-expiry signal.

Add unit coverage beside the existing network/API reauthentication tests for an authenticated request that rejects with an HttpsError auth status: verify it attempts Authenticate, retries the original request on success, and clears/redirects on failed reauthentication. Also keep the existing jsonCode 407 tests unchanged so the current response-body flow is not regressed.

Scope boundaries: files touched should be src/libs/Middleware/Reauthentication.ts plus the existing network/API reauthentication tests under tests/unit/NetworkTest.tsx or tests/unit/APITest.ts. Platforms affected are web, mWeb, and native through the shared API middleware, with the reported desktop web flow covered directly. Do not change HttpUtils.processHTTPRequest(), SignInRedirect, AppNavigator, Session.signOutAndRedirectToSignIn(), or backend/API contracts.

What alternative solutions did you explore? (Optional)

I considered adding a foreground timer or AppState watcher around SESSION.creationDate, but that would bypass the existing Expensify reauthentication contract and could sign users out even when the stored autogenerated credentials can refresh the session.

I also considered changing HttpUtils to convert every non-OK auth response into jsonCode 407, but that is too broad because request-specific non-OK responses should still be logged/handled as HTTP failures. Handling auth-status errors inside the Reauthentication middleware keeps the fix at the existing auth boundary.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @brunovjk (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022054610494997573872

[aswin-s]

Please re-state the problem that we are trying to solve in this issue.

When a user's session expires on the backend and they attempt any action whose request lacks retry metadata (e.g., legacy API requests or those prepared without going through the standard write branch), the Reauthentication middleware silently resolves the 407 NOT_AUTHENTICATED response without redirecting to sign-in or clearing the session. This leaves the user with an expired session, unable to perform any action, but still appearing logged in with no indication of the problem or how to recover.

What is the root cause of that problem?

The bug originates in src/libs/Middleware/Reauthentication.ts in the Reauthentication function at lines 73–88. When a request receives a 407 response and has no shouldRetry flag and no apiRequestType metadata, the middleware checks (!shouldRetry && !apiRequestType) || skipReauthentication at line 79 and takes an early-return path that directly resolves the 407 response to the caller without invoking reauthenticate() or redirectToSignIn(). This means the session is never torn down and the user is never notified of the expiration.

App/src/libs/Middleware/Reauthentication.ts

Lines 73 to 88 in c5403b4

	const shouldRetry = request?.data?.shouldRetry;
	const apiRequestType = request?.data?.apiRequestType;
	// For the SignInWithShortLivedAuthToken command, if the short token expires, the server returns a 407 error,
	// and credentials are still empty at this time, which causes reauthenticate to throw an error (requireParameters),
	// and the subsequent SaveResponseInOnyx also cannot be executed, so we need this parameter to skip the reauthentication logic.
	const skipReauthentication = request?.data?.skipReauthentication;
	if ((!shouldRetry && !apiRequestType) || skipReauthentication) {
	if (isFromSequentialQueue) {
	return data;
	}
	if (request.resolve) {
	request.resolve(data);
	}
	return data;

The correct pattern can be seen in the retryReauthenticate function in the same file, which catches authentication failures and calls redirectToSignIn() with an error message to sign out the user and redirect them to the login screen:

App/src/libs/Middleware/Reauthentication.ts

Lines 64 to 88 in c5403b4

	if (data.jsonCode === CONST.JSON_CODE.NOT_AUTHENTICATED) {
	if (getIsOffline()) {
	// If we are offline and somehow handling this response we do not want to reauthenticate
	throw new Error('Unable to reauthenticate because we are offline');
	}
	// There are some API requests that should not be retried when there is an auth failure like
	// creating and deleting logins. In those cases, they should handle the original response instead
	// of the new response created by handleExpiredAuthToken.
	const shouldRetry = request?.data?.shouldRetry;
	const apiRequestType = request?.data?.apiRequestType;
	// For the SignInWithShortLivedAuthToken command, if the short token expires, the server returns a 407 error,
	// and credentials are still empty at this time, which causes reauthenticate to throw an error (requireParameters),
	// and the subsequent SaveResponseInOnyx also cannot be executed, so we need this parameter to skip the reauthentication logic.
	const skipReauthentication = request?.data?.skipReauthentication;
	if ((!shouldRetry && !apiRequestType) || skipReauthentication) {
	if (isFromSequentialQueue) {
	return data;
	}
	if (request.resolve) {
	request.resolve(data);
	}
	return data;

Note that shouldRetry and apiRequestType are sourced from the request object and may be undefined or null when a request is constructed outside the standard write path. The condition (!shouldRetry && !apiRequestType) correctly treats both falsy and nullish values as the "no retry metadata" case, so no additional null guard is needed for the condition itself. However, the fix must ensure that before calling redirectToSignIn, we confirm the response jsonCode is actually 407 (NOT_AUTHENTICATED) rather than some other error that coincidentally reaches this branch.

What changes do you think we should make in order to solve the problem?

1. File: src/libs/Middleware/Reauthentication.ts
   Function: Reauthentication
   Description: In the early-return branch at line 79 where (!shouldRetry && !apiRequestType) || skipReauthentication is true, replace the unconditional direct resolution with the following logic:

   • If skipReauthentication is explicitly true, preserve the existing early return as-is. This covers the intentional short-lived token auth case where reauthentication must be skipped.
   • Otherwise (i.e., !shouldRetry && !apiRequestType with skipReauthentication falsy or absent), check whether response.jsonCode === 407. If it is, call redirectToSignIn('sessionExpiredMessageKey') to sign the user out and display the expired-session message. If the response is not a 407, fall through to the existing resolution so non-auth errors in this branch are unaffected.

   Splitting the two cases in the condition means skipReauthentication no longer silently absorbs session-expiry 407s on requests that set it for unrelated reasons.

   Pseudocode for the revised branch:

   if ((!shouldRetry && !apiRequestType) || skipReauthentication) {
       if (skipReauthentication) {
           return response;
       }
       // shouldRetry and apiRequestType are both falsy/nullish
       if (response.jsonCode === 407) {
           redirectToSignIn(ERRORS.SESSION_EXPIRED);
           return response;
       }
       return response;
   }

   The platform-level sign-out that redirectToSignIn triggers already handles both web and mobile cleanup paths (Onyx session clear + navigation reset), so no additional platform-specific branching is required in this middleware.

2. File: src/languages/en.ts
   Function: session (or the appropriate top-level error/auth key group)
   Description: Add the SESSION_EXPIRED string key. Only the English source key needs to be manually added; the Spanish (es.ts) and other locale files are generated from the English source, so adding the key in en.ts is the single required manual change. Verify the key group exists before inserting — if a session or errors group already has auth-related strings, add the new key there for consistency rather than creating a new group.

What alternative solutions did you explore?

N/A

[aswin-s]

Updated the proposal above to tighten 4 edge cases (additional guards and broader coverage).

[oqildev]

Proposal

What is the root cause of that problem?

I traced the symptom (request fails after the server-side session expires, but no sign-out and no redirect) to a commented-out guard in the reauthenticate library that was disabled during the #fireroom-2026-01-28-user-signout incident and never put back.

Chain for "no sign-out when session expires":

1. The expired request returns jsonCode === 407 (CONST.JSON_CODE.NOT_AUTHENTICATED, defined here: https://github.com/Expensify/App/blob/main/src/CONST/index.ts#L2181-L2191).
2. The Reauthentication middleware sees the 407 and calls reauthenticate(): https://github.com/Expensify/App/blob/main/src/libs/Middleware/Reauthentication.ts#L64-L97
3. reauthenticate() flips setIsAuthenticating(true) (which pauses the request queue), then runs the credentials guard: https://github.com/Expensify/App/blob/main/src/libs/Reauthentication.ts#L119-L147
4. When autoGeneratedLogin / autoGeneratedPassword are missing (very real in practice — happens after a SAML reauth at https://github.com/Expensify/App/blob/main/src/libs/actions/SignInRedirect.ts#L84-L90 which sets both to null, after multi-tab Onyx.clear, or during a delegate session unwind), the guard logs "No credentials available, redirecting to sign in" — but the actual setIsAuthenticating(false) / redirectToSignIn(...) / return false lines are commented out:
   https://github.com/Expensify/App/blob/main/src/libs/Reauthentication.ts#L140-L147
5. Execution falls through to Authenticate({ partnerUserID: undefined, partnerUserSecret: undefined }). Inside Authenticate, requireParameters throws and the catch calls redirectToSignIn(errorMessage) — but it returns Promise.resolve() with undefined: https://github.com/Expensify/App/blob/main/src/libs/Reauthentication.ts#L62-L77
6. Back in the outer .then((response) => { if (!response) return false; }) (https://github.com/Expensify/App/blob/main/src/libs/Reauthentication.ts#L162-L165) the promise resolves to false without ever calling setIsAuthenticating(false).
7. The Network store stays stuck in isAuthenticating === true. Every subsequent 407 hits the early-out at https://github.com/Expensify/App/blob/main/src/libs/Middleware/Reauthentication.ts#L91-L95 which just calls replayMainQueue(request) and returns the 407 data — so requests silently fail forever, no sign-out, no redirect. That is exactly the reported symptom: "request failure without sign-out".

The "boring place" check applies here verbatim — the comment literally says "The following lines are commented out to test if it's the cause of #fireroom-2026-01-28-user-signout" and it was never reverted.

What changes do you think we should make in order to solve the problem?

The fix belongs in the data/auth layer, not in the middleware or UI. Restore the three commented-out lines in reauthenticate() at https://github.com/Expensify/App/blob/main/src/libs/Reauthentication.ts#L140-L147 so that when credentials are missing we:

1. Call setIsAuthenticating(false) — unpauses the network queue so we don't deadlock subsequent requests.
2. Call redirectToSignIn('No credentials available') — clears Onyx (auth token), which is the actual signal the app uses to render the sign-in page.
3. return false — short-circuits before Authenticate() is invoked with undefined partner credentials (avoids the silent requireParameters throw → undefined-response branch that drops setIsAuthenticating(false)).

Edge cases to keep in mind while restoring:

• Offline: getIsOffline() is already checked in the middleware before reauth at https://github.com/Expensify/App/blob/main/src/libs/Middleware/Reauthentication.ts#L65-L68, so the restored guard does not need to re-check.
• SAML reauth: the SAML branch above (https://github.com/Expensify/App/blob/main/src/libs/Reauthentication.ts#L133-L138) already does the setIsAuthenticating(false) + redirectToSignIn(undefined, true) + return false triplet — restoring the credentials guard makes the two paths symmetric.
• Delegate session unwind: restoreDelegateSession swaps credentials. If reauth fires mid-swap and credentials are momentarily missing, redirecting to sign in is the correct fallback — there is no valid recovery without credentials.
• Original fireroom concern (over-aggressive sign-outs): the historical worry was that a transient empty credentials from an Onyx race triggered a real sign-out. The proper guard against that is hasReadRequiredDataFromStorage() (already awaited at https://github.com/Expensify/App/blob/main/src/libs/Reauthentication.ts#L126), which guarantees Onyx has loaded before the credentials check. Commenting out the redirect was the wrong fix.

Note: PR #89680 (commit 944401b5534, "Restore commented-out code") already restores exactly these three lines on main — the proposal is to make sure that fix is what ships, and not get reverted again the next time a sign-out fireroom strikes.

What alternative solutions did you explore? (Optional)

• Reset setIsAuthenticating(false) in the middleware's outer .catch() at https://github.com/Expensify/App/blob/main/src/libs/Middleware/Reauthentication.ts#L136-L146. Rejected: the inner reauthenticate() resolves with false instead of throwing in this code path, so the outer .catch() is never entered. It would also leave the user signed in with an invalid token until they manually retry — a worse UX than just redirecting.
• Detect the stuck isAuthenticating state from redirectToSignIn itself by calling setIsAuthenticating(false) inside clearStorageAndRedirect. Rejected: SignInRedirect.ts does not import from NetworkStore and adding that coupling pulls auth-flow concerns into a generic "wipe Onyx" helper. The right place to clean up the flag is the function that set it.
• Treat the 407 in the middleware and skip the reauthenticate() call entirely when credentials are missing. Rejected: the middleware does not currently read CREDENTIALS from Onyx, and pushing that knowledge up the stack duplicates the check that already exists (and is correct) inside reauthenticate() — it just needs its return path restored.