[$250] iOS - Wallet - App logs out user and crashes after verified account in enable wallet flow

[jponikarchuk]

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: v9.3.69-3
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-27461/folder/13176687/41236661/1401787352?q=wallet&issue_type=jira&sort=-identifier
Email or phone of affected tester (no customers): leungbratt6+1105@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 14 / iOS 26.1
App Component: User Settings

Action Performed:

1. Open the iOS NewDot app
2. Log in with a brand new account -> Select something else
3. Navigate to Wallet
4. Enable wallet -> Copy then Paste the magic code (important)
5. Force close the app, then reopen
6. From the OD view -> Tap on the Hamburger menu -> Settings

Expected Result:

App returns to the Add bank flow

Actual Result:

App logs out the user, and after closing and reopening the OD app display then crashes

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

logs.txt

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022053745796969713367
• Upwork Job ID: 2053745796969713367
• Last Price Increase: 2026-05-25

[MelvinBot]

Proposal

What is the root cause of that problem?

When a brand new (unvalidated) account taps "Enable Wallet", the app redirects to DynamicVerifyAccountPage for magic code verification before proceeding. This calls validateSecondaryLogin, which is a persisted WRITE command that optimistically updates ONYXKEYS.ACCOUNT and, on success, sets account.validated = true.

The likely root cause is that force-closing the app during or shortly after the ValidateSecondaryLogin API call corrupts persisted Onyx state — specifically the session/auth token. Two mechanisms can cause this:

1. Backend token rotation on account validation: When the backend transitions an account from unvalidated → validated via ValidateSecondaryLogin, it may return updated session data (new authToken) in the API response's onyxData. If the app is force-closed before this new token is persisted to Onyx's SQLite storage, the old token remains on disk but is now invalid server-side.

2. Interrupted Onyx persistence: Force-closing mid-write can leave ONYXKEYS.SESSION partially written in SQLite. On restart, authToken may be missing or null.

On reopen, the app loads stale/corrupted session data → useIsAuthenticated reads a falsy authToken → user appears logged out. If instead the old token is present but invalid, API calls return 407 → the reauthentication middleware in Reauthentication.ts attempts re-auth → if credentials.autoGeneratedLogin or autoGeneratedPassword are also missing/stale, it calls redirectToSignIn() → Onyx.clear() wipes all state.

The crash then occurs because Onyx.clear() wipes wallet/navigation data while components connected to those keys may still be rendering, or because the cleanupSession() call during AuthScreens unmount races with navigation state reset.

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

The fix should ensure the wallet verification flow is resilient to force-close by not issuing a persisted WRITE for ValidateSecondaryLogin until the session state is safely persisted, or by adding guards that prevent the crash on the logout transition:

1. Guard NavigationRoot against stale navigation state on auth transitions: In NavigationRoot.tsx, when the app cold-starts with authenticated = false, ensure lastVisitedPath restoration is skipped (line ~133 already checks authenticated, but there may be a brief window where authenticated is initially truthy from stale Onyx before flipping to false after Onyx.clear()).

2. Add null-safety in EnablePayments.tsx and wallet-related screens: Ensure that if userWallet or other wallet Onyx keys are cleared mid-render (due to Onyx.clear()), the component gracefully returns a loading/null state rather than crashing on undefined access.

3. Investigate if ValidateSecondaryLogin backend response rotates auth tokens — if so, this should be documented and the client should handle the force-close case by reauthenticating gracefully on restart rather than crashing.

What alternative solutions did you explore? (Optional)

• Making ValidateSecondaryLogin a non-persisted WRITE so it doesn't replay on restart — rejected because the user would lose their validation progress.
• Preserving wallet-related Onyx keys during Onyx.clear() — rejected because that could leave stale wallet state that causes other issues.

Investigation details

Key code paths:

• WalletPage/index.tsx:884-888: Checks isUserValidated before navigating to Enable Payments; if not validated, redirects to DynamicVerifyAccountPage
• User.ts:582-614: validateSecondaryLogin optimistically merges DEFAULT_ACCOUNT_DATA into ONYXKEYS.ACCOUNT, then sets validated: true on success
• Reauthentication.ts:141-146: Redirects to sign-in if autoGeneratedLogin/autoGeneratedPassword are missing
• SignInRedirect.ts:46-111: clearStorageAndRedirect calls Onyx.clear(), wiping all non-preserved keys including USER_WALLET, WALLET_TERMS, and SESSION
• NavigationRoot.tsx:111-150: initialState computed once with useMemo([], []) — if authenticated is briefly truthy from stale Onyx then flips to false, the initial nav state may reference auth-required routes
• useIsAuthenticated.tsx:5-9: Auth determined solely by presence of session.authToken
• Onfido data uses RAM_ONLY_WALLET_ONFIDO key (setup/index.ts:69) — not persisted to disk, lost on force-close

Evidence chain:

1. New user → unvalidated account → wallet flow redirects to magic code verification
2. Magic code paste triggers validateSecondaryLogin (persisted WRITE)
3. Force close interrupts either (a) the Onyx persistence of the API response, or (b) the server-side token rotation response
4. On restart: stale/missing authToken → appears logged out OR reauthentication fails → Onyx.clear() → logged out
5. Crash from navigation/component state mismatch during the logout transition

Confidence: Medium — Code evidence strongly supports the logout mechanism, but the exact crash stack trace would confirm the specific crash point. The backend behavior during ValidateSecondaryLogin (whether it rotates tokens) would confirm the trigger.

---

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.

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

This is a HybridApp issue. The repro starts on a brand-new account signed up on NewDot, so the user only has a NewDot session — OldDot was never authenticated for this user. After enabling Wallet → entering the magic code → being placed in the Add Bank Account flow → force-closing the app, the next launch starts in OldDot (the default landing for HybridApp). Tapping the hamburger → Settings transitions back to NewDot and triggers setupNewDotAfterTransitionFromOldDot, which decides whether the user "switched account on OldDot".

The check is a single equality comparison between the OldDot email and the current NewDot email:

https://github.com/Expensify/App/blob/main/src/libs/actions/Session/index.ts#L678-L684

const currentUserEmail = getCurrentUserEmail();

// If ND and OD account are the same - do nothing
if (hybridApp?.delegateAccessData?.oldDotCurrentUserEmail === currentUserEmail) {
    Log.info('[HybridApp] User did not switch account on OldDot side');
    return;
}

For a brand-new NewDot account, oldDotCurrentUserEmail is undefined/empty while currentUserEmail is the freshly signed-up email. They aren't equal, so the code falls into the "OD-switched" branch at https://github.com/Expensify/App/blob/main/src/libs/actions/Session/index.ts#L720-L746 and does:

1. clearOnyxForDelegateTransition() — wipes the NewDot session, credentials, account, and the in-progress wallet/AddBankAccount state.
2. Onyx.multiSet with SESSION = { email: undefined, authToken: undefined, accountID: undefined, ... } from the empty OldDot delegate data.
3. openApp() is called with that empty session, which fails auth → the user appears logged out, and the next navigation (the queued RHP route for /settings/wallet/enable-payments) crashes because it tries to render with no session/account.

So the regression isn't in the wallet flow itself — the wallet just gets us into a real-but-not-yet-mirrored-to-OldDot state. The transition handler then mistakes "OldDot was never signed in" for "OldDot switched to a different user" and erases the valid NewDot session.

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

The "switched account" branch should only fire when OldDot actually has an account that differs from NewDot's. If oldDotCurrentUserEmail is missing, there is nothing on OldDot to apply, so we should short-circuit just like the equal-emails case.

 const currentUserEmail = getCurrentUserEmail();

-// If ND and OD account are the same - do nothing
-if (hybridApp?.delegateAccessData?.oldDotCurrentUserEmail === currentUserEmail) {
-    Log.info('[HybridApp] User did not switch account on OldDot side');
+const oldDotCurrentUserEmail = hybridApp?.delegateAccessData?.oldDotCurrentUserEmail;
+
+// If ND and OD account are the same, OR OldDot has no signed-in user yet
+// (e.g. brand-new account that signed up on NewDot only), do nothing —
+// there is no OldDot session to migrate into NewDot.
+if (!oldDotCurrentUserEmail || oldDotCurrentUserEmail === currentUserEmail) {
+    Log.info('[HybridApp] No OldDot account switch detected, keeping NewDot session');
     return;
 }

Secondary improvement: in the "switched account" branch we currently overwrite the NewDot session with oldDotCurrentAuthToken/oldDotCurrentAccountID unconditionally. We should also bail out (or at minimum skip the clearOnyxForDelegateTransition + multiSet) when oldDotCurrentAuthToken is empty, so a partially populated delegateAccessData payload can never wipe a valid NewDot session.

With the guard in place, the user lands back on NewDot with their session intact, the wallet RHP rehydrates userWallet, and EnablePayments renders the ADD_BANK_ACCOUNT step as expected.

What alternative solutions did you explore? (Optional)

• Persisting and replaying the wallet currentStep on app cold start. This would only paper over the symptom — the user would still be logged out, and the crash would surface elsewhere as soon as any authenticated screen tried to render.
• Forcing an OldDot sign-in immediately after a NewDot sign-up so oldDotCurrentUserEmail is always populated. Heavier change, requires backend coordination, and still leaves the comparison fragile if OldDot's session ever lags behind NewDot's (e.g., after a session refresh on NewDot only). Fixing the guard in setupNewDotAfterTransitionFromOldDot is the smaller, more defensive fix.
• Stashing the NewDot session before clearing (STASHED_SESSION/STASHED_CREDENTIALS) for non-delegate flows too. Would recover the session after the fact but adds restore logic for a state we shouldn't be entering in the first place.

[melvin-bot]

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

[KJ21-ENG]

Replaces my earlier proposal. Media and post-comment review confirmed the HybridApp bootstrap/OldDot handoff root cause, and this update adds the video timing plus explicit alternatives for the new bot and human proposals.

Proposal

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

On iOS HybridApp, a user who starts the Wallet enablement flow from NewDot, validates the account with the magic code, then force-closes/reopens can be pushed back to OldDot instead of resuming the Add bank flow. When they open Settings from OldDot, NewDot can clear the session and show the user as logged out/crashed instead of continuing wallet setup.

The attached video matches that sequence: after the code is pasted and submitted, the app falls back to the NewDot sign-in surface, then the relaunch shows OldDot Home/Settings before iOS reports the Expensify app crash.

What is the root cause of that problem?

The Wallet enable button sends an unvalidated user to the contextual verify-account route instead of directly opening the payments flow:

App/src/pages/settings/Wallet/WalletPage/index.tsx

Lines 884 to 888 in b7c38b1

	if (!isUserValidated) {
	Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.VERIFY_ACCOUNT.path));
	return;
	}
	Navigation.navigate(ROUTES.SETTINGS_ENABLE_PAYMENTS);

After the magic code succeeds, VerifyAccountPageBase observes account.validated and force-replaces to the supplied forward route, which is settings/wallet/enable-payments for the Wallet entry point:

App/src/pages/settings/VerifyAccountPageBase.tsx

Lines 61 to 74 in b7c38b1

	// Handle navigation once the user is validated
	useEffect(() => {
	if (!isUserValidated) {
	return;
	}
	onValidationSuccess?.();
	if (navigateForwardTo) {
	Navigation.navigate(navigateForwardTo, {forceReplace: true});
	} else {
	handleCloseWithFallback();
	}
	}, [isUserValidated, navigateForwardTo, handleCloseWithFallback, handleClose, onValidationSuccess]);

App/src/pages/settings/DynamicVerifyAccountPage.tsx

Lines 6 to 18 in b7c38b1

	function DynamicVerifyAccountPage() {
	const backPath = useDynamicBackPath(DYNAMIC_ROUTES.VERIFY_ACCOUNT.path);
	let forwardPath = backPath;
	if (backPath === ROUTES.SETTINGS_WALLET) {
	forwardPath = ROUTES.SETTINGS_ENABLE_PAYMENTS;
	}
	return (
	<VerifyAccountPageBase
	navigateBackTo={backPath}
	navigateForwardTo={forwardPath}
	/>

The iOS HybridApp bootstrap subscriber in src/libs/HybridApp.ts is also subscribed to ACCOUNT, and its guard only checks for session.authToken, hybridApp.useNewDotSignInPage, stored credentials, and the two 2FA fields. It does not check whether NewDot auth screens are already ready/visible. So a later ACCOUNT update from wallet account verification can satisfy the same initial-sign-in guard and run the OldDot sign-in/experience-choice logic again while the user is already in NewDot:

App/src/libs/HybridApp.ts

Lines 75 to 123 in b7c38b1

	function signInToOldDotAndChooseExperience(
	hybridApp: OnyxEntry<HybridApp>,
	tryNewDot: OnyxEntry<TryNewDot>,
	credentials: OnyxEntry<Credentials>,
	session: OnyxEntry<Session>,
	account: OnyxEntry<Account>,
	) {
	if (!CONFIG.IS_HYBRID_APP) {
	return;
	}
	if (!session?.authToken || !hybridApp?.useNewDotSignInPage) {
	return;
	}
	if (isAnonymousUser(session)) {
	setReadyToShowAuthScreens(true);
	return;
	}
	if (!credentials?.autoGeneratedLogin || !credentials?.autoGeneratedPassword || account?.requiresTwoFactorAuth === undefined || account?.needsTwoFactorAuthSetup === undefined) {
	return;
	}
	// Skip if we're already in the signing in flow, preventing multiple calls to signInToOldDot
	if (session?.autoAuthState === CONST.AUTO_AUTH_STATE.SIGNING_IN) {
	return;
	}
	Log.info(`[HybridApp] Performing sign-in on OldDot side`);
	HybridAppModule.signInToOldDot({
	autoGeneratedLogin: credentials.autoGeneratedLogin,
	autoGeneratedPassword: credentials.autoGeneratedPassword,
	authToken: session.authToken,
	email: getCurrentUserEmail() ?? '',
	// eslint-disable-next-line rulesdir/no-default-id-values
	policyID: activePolicyID ?? '',
	signingInWithSAML: hybridApp?.signingInWithSAML ?? false,
	});
	if (tryNewDot !== undefined) {
	setUseNewDotSignInPage(false).then(() => {
	if (shouldUseOldApp(tryNewDot) && (!account?.needsTwoFactorAuthSetup || account?.requiresTwoFactorAuth)) {
	closeReactNativeApp({shouldSetNVP: false, isTrackingGPS: false});
	} else {
	setReadyToShowAuthScreens(true);
	}
	});
	}

For users whose tryNewDot state resolves to OldDot, that late rerun calls closeReactNativeApp(), which sets HYBRID_APP.closingReactNativeApp and closes NewDot:

App/src/libs/actions/HybridApp/index.ts

Lines 108 to 118 in b7c38b1

	if (!shouldIgnoreTryNewDotLoading && shouldBlockOldAppExit(currentTryNewDot, isLoadingTryNewDot, shouldSetNVP)) {
	return;
	}
	Navigation.clearPreloadedRoutes();
	if (CONFIG.IS_HYBRID_APP) {
	Onyx.merge(ONYXKEYS.HYBRID_APP, {closingReactNativeApp: true});
	}
	// eslint-disable-next-line no-restricted-properties
	HybridAppModule.closeReactNativeApp({shouldSetNVP});

On the next transition back from OldDot, setupNewDotAfterTransitionFromOldDot() clears Onyx when the native hybrid settings say NewDot sign-in is in progress (useNewDotSignInPage), which matches the reported logout/crash after reopening Settings from OldDot:

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

Lines 651 to 664 in b7c38b1

	const clearOnyxIfSigningIn = () => {
	if (!hybridApp.useNewDotSignInPage) {
	return Promise.resolve();
	}
	// Don't clear Onyx when using imported state to preserve imported data (reports, transactions, etc.)
	if (isUsingImportedState) {
	Log.info('[HybridApp] Skipping Onyx clear because using imported state');
	return Promise.resolve();
	}
	Log.info(`[HybridApp] Clearing onyx after transition from OldDot. useNewDotSignInPage set to ${hybridApp.useNewDotSignInPage}`);
	return redirectToSignIn();
	};

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

Constrain signInToOldDotAndChooseExperience() to the actual HybridApp sign-in/bootstrap window. In src/libs/HybridApp.ts, return early when hybridApp.readyToShowAuthScreens is already true before calling HybridAppModule.signInToOldDot() or closeReactNativeApp(). That keeps the initial NewDot-to-OldDot credential sync intact, but prevents normal in-app account mutations such as wallet verify-account success from being interpreted as a fresh sign-in bootstrap.

Add/extend a unit test around the HybridApp subscriber behavior: with useNewDotSignInPage: true, valid session/credentials, readyToShowAuthScreens: true, and a post-auth ACCOUNT update that fills requiresTwoFactorAuth / needsTwoFactorAuthSetup, the code must not call signInToOldDot, setUseNewDotSignInPage(false), or closeReactNativeApp. Keep the existing initial-sign-in case covered so bootstrap still works before auth screens are marked ready.

Scope boundaries:

• Files touched: src/libs/HybridApp.ts - signInToOldDotAndChooseExperience() (lines 75-123); tests/unit/HybridAppActionsTest.ts or the closest HybridApp unit coverage - add the post-auth ACCOUNT update regression case.
• Platforms: iOS HybridApp only; standalone native, web, and mWeb do not use CONFIG.IS_HYBRID_APP or HybridAppModule.closeReactNativeApp().
• Code paths / callers explicitly NOT touched: wallet step selection in src/pages/EnablePayments/EnablePayments.tsx, verify-code submission in src/pages/settings/VerifyAccountPageBase.tsx, and OldDot delegate-account transition handling in setupNewDotAfterTransitionFromOldDot().
• API contracts or backend behavior changes: none.

What alternative solutions did you explore? (Optional)

I considered changing the Wallet verify-account route to bypass DynamicVerifyAccountPage, but the route already forwards Wallet validation to SETTINGS_ENABLE_PAYMENTS; changing it would not stop the HybridApp module-level subscriber from reacting to the later ACCOUNT update. I also considered suppressing closeReactNativeApp() only in the Wallet flow, but that would leave the broader bug in place for any post-auth account update that satisfies the same bootstrap guard.

MelvinBot and MobileMage proposed variants of a ValidateSecondaryLogin / persisted-write failure theory. I do not think that is the root cause: the verified local action only writes LOGIN_LIST and ACCOUNT, and its failure data already clears ACCOUNT.isLoading:

App/src/libs/actions/User.ts

Lines 565 to 655 in b7c38b1

	function validateSecondaryLogin(contactMethod: string, validateCode: string, formatPhoneNumber: LocaleContextProps['formatPhoneNumber'], shouldResetActionCode?: boolean) {
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.LOGIN_LIST | typeof ONYXKEYS.ACCOUNT>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.LOGIN_LIST,
	value: {
	[contactMethod]: {
	errorFields: {
	validateLogin: null,
	validateCodeSent: null,
	},
	pendingFields: {
	validateLogin: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	},
	},
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.ACCOUNT,
	value: {
	...CONST.DEFAULT_ACCOUNT_DATA,
	isLoading: true,
	},
	},
	];
	const successData: Array<OnyxUpdate<typeof ONYXKEYS.LOGIN_LIST | typeof ONYXKEYS.ACCOUNT | typeof ONYXKEYS.VALIDATE_ACTION_CODE>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.LOGIN_LIST,
	value: {
	[contactMethod]: {
	validatedDate: DateUtils.getDBTime(),
	pendingFields: {
	validateLogin: null,
	},
	errorFields: {
	validateCodeSent: null,
	},
	},
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.ACCOUNT,
	value: {
	isLoading: false,
	validated: true,
	},
	},
	];
	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.LOGIN_LIST | typeof ONYXKEYS.ACCOUNT | typeof ONYXKEYS.VALIDATE_ACTION_CODE>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.LOGIN_LIST,
	value: {
	[contactMethod]: {
	errorFields: {
	validateLogin: ErrorUtils.getMicroSecondOnyxErrorWithTranslationKey('contacts.genericFailureMessages.validateSecondaryLogin'),
	validateCodeSent: null,
	},
	pendingFields: {
	validateLogin: null,
	},
	},
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.ACCOUNT,
	value: {isLoading: false},
	},
	];
	// Sometimes we will also need to reset the validateCodeSent of ONYXKEYS.VALIDATE_ACTION_CODE in order to receive the magic code next time we open the ValidateCodeActionModal.
	if (shouldResetActionCode) {
	const optimisticResetActionCode = {
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.VALIDATE_ACTION_CODE,
	value: {
	validateCodeSent: null,
	},
	};
	successData.push(optimisticResetActionCode);
	failureData.push(optimisticResetActionCode);
	}
	const parameters: ValidateSecondaryLoginParams = {partnerUserID: contactMethod, validateCode};
	API.write(WRITE_COMMANDS.VALIDATE_SECONDARY_LOGIN, parameters, {optimisticData, successData, failureData});

I also considered guarding setupNewDotAfterTransitionFromOldDot() against empty OldDot delegate data. That may be a useful hardening follow-up, but it is downstream of the first wrong transition: NewDot is sent back to OldDot because the ACCOUNT subscriber reruns HybridApp bootstrap after the user is already authenticated and visible in NewDot.

[MobileMage]

Proposal

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

When a brand-new user goes through the Enable Wallet flow on iOS HybridApp — specifically by copying and pasting the magic code on the verify-account step — force-closing and reopening the app causes the user to be logged out, and subsequently the OldDot view crashes.

What is the root cause of that problem?

The verify-account step for the wallet flow uses VerifyAccountPageBase, which calls validateSecondaryLogin with shouldResetActionCode = true. That call writes { isLoading: true } to ONYXKEYS.ACCOUNT as optimistic data, and the corresponding VALIDATE_SECONDARY_LOGIN API call is queued. When the user force-closes the app before the network response arrives, Onyx persists both the stale optimistic state (ACCOUNT.isLoading = true) and the pending write-queue entry. On reopen, the pending VALIDATE_SECONDARY_LOGIN request is replayed — but simultaneously the app reinitialises the HybridApp session via getShortLivedLoginParams, which also merges { ...CONST.DEFAULT_ACCOUNT_DATA, isLoading: true } into ONYXKEYS.ACCOUNT as its own optimistic data and sets SESSION.signedInWithShortLivedAuthToken = true. The finallyData for getShortLivedLoginParams clears isLoading and nullifies signedInWithShortLivedAuthToken, but if the replayed VALIDATE_SECONDARY_LOGIN fails (e.g. the code is already consumed) its failureData does not clear isLoading. The result is a corrupted account/session state — isLoading stuck at true and signedInWithShortLivedAuthToken potentially nulled — that the HybridApp authentication guard interprets as an unauthenticated session, triggering signOutAndRedirectToSignIn. The subsequent OldDot crash is a consequence of OldDot receiving a sign-out event while its own view is partially initialised.

The critical code path is in src/libs/actions/User.ts around validateSecondaryLogin, specifically that its failureData does not reset ACCOUNT.isLoading to false:

App/src/libs/actions/User.ts

Lines 617 to 638 in b7c38b1

	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.LOGIN_LIST | typeof ONYXKEYS.ACCOUNT | typeof ONYXKEYS.VALIDATE_ACTION_CODE>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.LOGIN_LIST,
	value: {
	[contactMethod]: {
	errorFields: {
	validateLogin: ErrorUtils.getMicroSecondOnyxErrorWithTranslationKey('contacts.genericFailureMessages.validateSecondaryLogin'),
	validateCodeSent: null,
	},
	pendingFields: {
	validateLogin: null,
	},
	},
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.ACCOUNT,
	value: {isLoading: false},
	},
	];

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

The failureData block of validateSecondaryLogin in src/libs/actions/User.ts must set ONYXKEYS.ACCOUNT.isLoading to false, exactly as the successData block already does. Currently failureData only merges { isLoading: false } into ONYXKEYS.ACCOUNT when the call fails — but looking at the code the failureData entry for ONYXKEYS.ACCOUNT only sets { isLoading: false } and does not include validated: false or any reset of the DEFAULT_ACCOUNT_DATA fields that were spread in by the optimistic update. To be safe, the failure entry should also null out validated so that a failed replay on reopen cannot leave an account in a partially-validated state. In addition, VerifyAccountPageBase fires validateSecondaryLogin whenever the user submits the code, but it has no guard against being called while the previous request is still in-flight (i.e. while ACCOUNT.isLoading is true). Adding a guard in handleSubmitForm in src/pages/settings/VerifyAccountPageBase.tsx to skip submission when account?.isLoading is true will prevent the double-submission that the paste-then-force-close sequence can produce.

App/src/pages/settings/VerifyAccountPageBase.tsx

Lines 46 to 51 in b7c38b1

	const handleSubmitForm = useCallback(
	(validateCode: string) => {
	validateSecondaryLogin(contactMethod, validateCode, formatPhoneNumber, true);
	},
	[contactMethod, formatPhoneNumber],
	);

What alternative solutions did you explore? (Optional)

N/A

[melvin-bot]

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

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The issue occurs specifically when a user copies and pastes the magic code during the wallet verification flow on iOS, then force-closes and reopens the app. The paste action on iOS can trigger the native clipboard access prompt, and when combined with the app lifecycle (force close → reopen), something in the session/authentication state gets corrupted.

Looking at the magic code input handling, the validateMagicCode / sign-in flow in src/libs/actions/Session/index.ts handles the magic code submission. When a user pastes (rather than types) a magic code, iOS may fire the input event in a way that causes the code to be submitted with unexpected state — particularly around how the autoValidate logic works in src/components/MagicCodeInput/index.tsx.

The likely root cause is in how the MagicCodeInput component handles pasted input on iOS: pasting fills all fields at once, which can trigger the onFulfill callback immediately. If the app is backgrounded/force-closed right after this fires (while an async validateMagicCode network call is in-flight), the session token response may arrive when the app is in an inconsistent state on relaunch — either partially authenticated or with stale/conflicting Onyx data — causing the auth layer to interpret this as an invalid session and sign the user out.

The specific area to look at is the autoValidate behavior in:
https://github.com/Expensify/App/blob/main/src/components/MagicCodeInput/index.tsx

and the session validation logic in:
https://github.com/Expensify/App/blob/main/src/libs/actions/Session/index.ts

When the app relaunches after a force-close mid-flow, ReconnectApp or OpenApp is called, but if there's a pending/partially-completed validateMagicCode response stored in Onyx with an error state, the app may incorrectly treat the current session as unauthenticated.

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

The fix should guard against processing a stale or in-flight validateMagicCode result on app relaunch. Specifically, we should clear any pending magic-code validation state from Onyx when the app is opened fresh (i.e., not from a background resume):

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

function signInWithMagicCode(magicCode: string) {
+   // Clear any previously stored magic code validation errors before attempting
+   Onyx.merge(ONYXKEYS.SESSION, {errors: null});
    // ... existing implementation
}

Additionally, in the MagicCodeInput component, we should debounce or guard the onFulfill callback on paste events specifically on iOS to prevent a race condition where the fulfillment fires before the component is in a stable state:

// src/components/MagicCodeInput/index.tsx

- if (inputValue.length === maxLength) {
-     onFulfill(inputValue);
+ if (inputValue.length === maxLength) {
+     // Use a small delay on iOS to avoid race conditions with paste events
+     const fulfillDelay = Browser.isMobileIOS() ? 100 : 0;
+     setTimeout(() => onFulfill(inputValue), fulfillDelay);
 }

Beyond these two diffs, I'd also make the following supporting changes in plain text:

• In src/libs/actions/Session/index.ts, when OpenApp or ReconnectApp is called on relaunch, verify that if the user is mid-wallet-setup (not fully authenticated), we don't attempt to process any residual Onyx session error keys that would trigger a sign-out.
• Review the AuthScreens navigator to ensure that a stale validateMagicCode error in Onyx doesn't route the user to the sign-out flow instead of back to the wallet enable screen.

What alternative solutions did you explore? (Optional)

One alternative would be to persist the wallet flow step in Onyx so that on relaunch the app can deterministically route back to the correct screen without re-evaluating authentication state. However, this would require more invasive changes to the wallet navigation flow and doesn't address the underlying crash caused by conflicting session state. The targeted debounce + state-clear approach is more surgical and less risky.

[github-actions]

⚠️ @dilshodmackbook-sketch Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).