[$250] Web - Account - Infinite loading page after click unlink in the email

[vincdargento]

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.4.34-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: https://github.com/Expensify/Expensify/issues/439070
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team

Action Performed:

1. Go to Settings-> Profile and add a secondary email(do not verify)
2. Login with secondary email and click on Unlink
3. Open Unlink Validation link email and click on the link
4. Verify that the unlink success message is displayed

Expected Result:

The chat creation should fail and an error should be shown

Actual Result:

Infinite loading page after click unlink in the email

Workaround:

N/A

Platforms:

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

Screenshots/Videos

Bug7181995_1781592657591.439070.mp4

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022077035652668462855
• Upwork Job ID: 2077035652668462855
• Last Price Increase: 2026-07-28

Issue Owner

Current Issue Owner: @ahmdshrif

[MelvinBot]

Proposal

What is the root cause of that problem?

UnlinkLoginPage shows a spinner that only clears via a loading→not-loading transition, but on this flow account.isLoading is set to true and never flipped back to false, so the page spins forever.

The chain:

1. The unlink email link opens UnlinkLoginPage, which is registered only on PublicScreens — i.e. the user is unauthenticated (no authToken) throughout this flow, since sign-in with the unverified secondary login never completes.
2. On mount it calls unlinkLogin(), which sets account.isLoading = true optimistically and fires API.write('UnlinkLogin', …) (Session/index.ts:1222-1270).
3. UnlinkLogin is not in the App's authToken-exempt list (enhanceParameters.ts:52-53 — only Log, Authenticate, BeginSignIn, SetPassword are exempt), so the request goes out with authToken: null and comes back NOT_AUTHENTICATED (407).
4. On 407 the reauth middleware tries to re-authenticate; with no credentials it fails and deliberately discards failureData/finallyData (Reauthentication.ts:114-118). That failureData was the only thing that would have reset isLoading to false.
5. isLoading is stuck true, so the navigate-back effect (UnlinkLoginPage.tsx:34-41) never fires → infinite spinner.

The page also has no error UI and no timeout, so any non-happy-path leaves the user on a bare spinner with no way out — unlike ValidateLoginPage, which drives an explicit state machine with terminal modals and a stuck-sign-in watchdog timeout.

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

Make the page self-healing so it can never spin forever (this fixes the reported symptom directly, and mirrors how ValidateLoginPage handles the same email-link pattern):

• In UnlinkLoginPage, add a timeout watchdog and a terminal error/message state: if the request doesn't resolve within a few seconds, stop the spinner and show a clear success/error message (or navigate back) instead of hanging. Reuse the STUCK_*_TIMEOUT_MS + Log.alert pattern from ValidateLoginPage.
• Stop gating navigation solely on a usePrevious true→false edge; also react to an explicit success/error account.message, which removes a batching fragility where a fast optimistic-then-terminal update could skip the edge.

Separately, the reason the request 407s is that UnlinkLogin runs on a public route without an authToken. Whether it should be sent as a public/unauthenticated command (i.e. added to the exempt list in enhanceParameters.ts) depends on whether the backend accepts UnlinkLogin unauthenticated — that requires backend confirmation and can't be verified from the App repo alone. The client-side self-healing fix above should land regardless.

What alternative solutions did you explore? (Optional)

Alternatives considered & confidence

• Pure frontend race (optimistic true and terminal false batched so prevIsLoading never latches true): possible on the happy path but a secondary fragility, not the cause of a consistent hang. Addressed by the "don't gate only on the usePrevious edge" change.
• Confidence: Medium. The App-side chain (public-only route → non-exempt authToken → 407 → discarded failureData → stuck isLoading) is verified with the file:line references above. What remains unverified without production logs / backend access is the exact server response for UnlinkLogin on this route (confirming the 407 and the failed reauth). Reply with @MelvinBot check logs if you'd like me to look for the UnlinkLogin request/response in production to confirm.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/96073) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-14 15:06:56 UTC.

Proposal

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

When a user with an unverified secondary email signs in with that secondary email, clicks Unlink, and then opens the unlink-validation email and clicks the link, the resulting page shows an infinite full-screen loading spinner instead of an unlink success (or error) message. This reproduces on Web/desktop (Windows Chrome, macOS Chrome/Safari) in both staging and production, and is not reported on native.

What is the root cause of that problem?

UnlinkLoginPage renders only a FullScreenLoadingIndicator and has no success/error UI of its own — its only exit is to navigate away once the request finishes. On mount it calls unlinkLogin(), and when account.isLoading transitions true→false it calls Navigation.goBack() with no arguments — see UnlinkLoginPage.tsx:34-41 and UnlinkLoginPage.tsx:46.

The problem is that Navigation.goBack() is a no-op here. Its guard early-returns when there is no backToRoute, shouldPopToSidebar is false, and navigationRef.current?.canGoBack() is false — see Navigation.ts:518-531. shouldPopToSidebar defaults to false and nothing in this flow sets it true (Navigation.ts:115), so the branch reduces to !canGoBack().

On a fresh browser tab opened from the email link, canGoBack() is false. SCREENS.UNLINK_LOGIN is registered as a top-level sibling public screen in PublicScreens.tsx:62-65 — not nested under the TAB_NAVIGATOR/SignInPage — and it is listed in the PUBLIC_SCREENS set documented as screens that "render on their own, with no tab navigator underneath" (getAdaptedStateFromPath.ts:39-53). Because the matched route is purely a public screen, the adapter's hasOnlyPublicScreens branch returns the matched state unmodified, with nothing prepended beneath it (getAdaptedStateFromPath.ts:379-385). So the stack has exactly one route ({routes: [{name: UNLINK_LOGIN}], index: 0}), canGoBack() returns false, the guard fires, goBack() returns without navigating, and the FullScreenLoadingIndicator is never replaced or unmounted — the spinner is infinite.

This is web-only because a fresh tab cold-loads only the matched UNLINK_LOGIN route with nothing beneath it, whereas on native the email link deep-links into an already-running app whose stack already has a route beneath the pushed screen, so canGoBack() is true and goBack() succeeds. It reproduces in both staging and production because the defect lives in shipped navigation logic with no environment gating.

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

Primary fix (root cause): In UnlinkLoginPage, stop leaving the page via Navigation.goBack() — which no-ops from a standalone public route — and instead imperatively reset the root navigator onto the public root that hosts SignInPage, so the tab always lands on a real, navigable screen where the unlink result can be shown.

This is exactly the precedent already used by its sibling public magic-link screen, ValidateLoginPage, at index.web.tsx:117-131, whose own comment states that "navigate/goBack no-op from the public /v/ route, so reset the stack to TAB_NAVIGATOR". UnlinkLoginPage is a sibling route on the same public root stack reached the same way (a magic link opened in a fresh tab), so the same remedy applies.

Concretely, replace the exit in the completion effect:

useEffect(() => {
    // Only navigate when the unlink login request is completed
    if (!prevIsLoading || account?.isLoading) {
        return;
    }
    // goBack() no-ops from a standalone public route (UNLINK_LOGIN is the only
    // stack entry on a fresh email-link tab, so canGoBack() is false). Reset to
    // TAB_NAVIGATOR — the public root that hosts SignInPage — so the result shows.
    Navigation.isNavigationReady().then(() => {
        navigationRef.reset({index: 0, routes: [{name: NAVIGATORS.TAB_NAVIGATOR}]});
    });
}, [prevIsLoading, account?.isLoading]);

We land on the public SignInPage, where account.message written by unlinkLogin on success (and the error path on failure) is surfaced, matching the expected "unlink success (or error) message".

Why this fixes it:

• Success scenario: unlinkLogin completes, account.isLoading flips true→false and account.message is set; instead of a no-op goBack(), we reset to TAB_NAVIGATOR, UnlinkLoginPage unmounts, and the user sees SignInPage with the unlink confirmation message — no more spinner.
• Failure scenario: the request resolves to failure, isLoading still flips back to false, and we still reset to the public root so the failure message is surfaced rather than the tab being stuck loading forever.

Regression safety: reset to NAVIGATORS.TAB_NAVIGATOR always targets a real base route that exists in every public-stack configuration (and is a safe target on native where a back stack also exists), so it cannot itself get stuck, and gating it behind Navigation.isNavigationReady() prevents resetting before the navigator mounts.

Result: clicking the unlink email link lands the user on the sign-in page showing the unlink success/error message instead of an infinite spinner, on web and native alike.

What alternative solutions did you explore? (Optional)

Alternative A — "It's a missed usePrevious edge from Onyx batching, so goBack() never fires." We rejected this: the optimistic isLoading:true write is synchronous off the mount effect and commits its own render, while the terminal isLoading:false write only arrives after the network round-trip resolves in a separate task — React 18 automatic batching only coalesces synchronous updates within one task, never two Onyx writes separated by an intervening committed render plus a network trip. Per usePrevious.ts:6-12 the ref updates in a post-commit effect and cannot skip an already-committed render, so prevIsLoading is true on the final render and Navigation.goBack() is called (UnlinkLoginPage.tsx:34-41). The edge is captured correctly; the failure is downstream in the no-op goBack().

Alternative B — "The UnlinkLogin request goes out unauthenticated, gets a 407, reauth discards failureData, and isLoading is never reset." This is a real and confirmed secondary failure mode: UnlinkLoginPage only mounts unauthenticated (via PublicScreens.tsx:62-65), UnlinkLogin is not in the auth-token-exempt list (enhanceParameters.ts:52-53), and on a failed reauth the middleware explicitly wipes failureData/finallyData (Reauthentication.ts:112-119), leaving isLoading stuck. We treat it as an additional fix worth following up rather than the primary one, because it does not by itself explain the reported repro where the request completes and isLoading transitions — and critically, even when the request fully succeeds, the no-op goBack() still strands the user on the spinner. The primary fix resolves the reported symptom; hardening the reauth/failureData path is a complementary improvement so a genuine 407 also surfaces an error message instead of hanging.

[aswin-s]

Proposal

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

On Web (Chrome/Safari), when a user clicks the unlink validation link in their email, the browser opens /unlink-login/... in a fresh tab and displays an infinite loading spinner. Expected behavior is that the unlink completes and a success message (or failure error) is shown on screen; instead the spinner never goes away.

What is the root cause of that problem?

In src/pages/UnlinkLoginPage.tsx:22-47, the page fires unlinkLogin(...) on mount and renders only a FullScreenLoadingIndicator. When the API completes, the effect at src/pages/UnlinkLoginPage.tsx:34-41 reacts to account.isLoading transitioning true → false (producer: src/libs/actions/Session/index.ts:1229 sets isLoading: true optimistically; :1238 and :1255 set it back to false in success/failure) by calling Navigation.goBack(). But when the user opens the validation link from email, the tab has no prior navigation history, so Navigation.goBack() is a no-op — the component stays mounted and the spinner renders forever. Nothing ever renders account.message = 'unlinkLoginForm.successfullyUnlinkedLogin' (set at src/libs/actions/Session/index.ts:1239) or the failure error to the user.

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

1. In src/pages/UnlinkLoginPage.tsx, after account.isLoading transitions to false, instead of only calling Navigation.goBack() unconditionally, render the resulting account.message / account.errors inline (reusing the same success/error UI as UnlinkLoginForm.tsx) so the user sees the unlink success message required by the repro (step 4).
2. Replace the bare Navigation.goBack() at UnlinkLoginPage.tsx:40 with a safe fallback: if there is no history to pop (fresh email-link tab), navigate to ROUTES.HOME / the sign-in route rather than calling goBack() which is a no-op and strands the spinner.
3. Only auto-navigate away on success; on failure, keep the page mounted and show the error (matches the issue's Expected Result of "an error should be shown").
4. Optionally clear account.message on unmount so the success text does not leak into the next screen.

What alternative solutions did you explore? (Optional)

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

The unlink email opens the public /u/:accountID/:validateCode route (ROUTES.UNLINK_LOGIN) directly from the email link (https://github.com/Expensify/App/blob/main/src/ROUTES.ts#L48-L55). UnlinkLoginPage starts unlinkLogin() on mount, waits for account.isLoading to change from true to false, and then calls Navigation.goBack() while always rendering only FullScreenLoadingIndicator (https://github.com/Expensify/App/blob/main/src/pages/UnlinkLoginPage.tsx#L28-L46). This works only when there is an in-app route to go back to. For a direct email deep link, the unlink route can be the only route in the navigation stack, and Navigation.goBack() explicitly returns without navigating when navigationRef.current?.canGoBack() is false (https://github.com/Expensify/App/blob/main/src/libs/Navigation/Navigation.ts#L518-L542). So after the API request completes, the success/error state is written to Onyx, but the app stays on a page that can only show a loader.

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

After the unlink request finishes, UnlinkLoginPage should navigate deterministically to the public sign-in root instead of relying on Navigation.goBack(). The public sign-in page is mounted under NAVIGATORS.TAB_NAVIGATOR in PublicScreens (https://github.com/Expensify/App/blob/main/src/libs/Navigation/AppNavigator/PublicScreens.tsx#L31-L44), so the unlink page should reset/replace the current route with that public root, or otherwise navigate to the root route, once account.isLoading flips back to false.

Keep unlinkLogin() as the source of truth for the API and Onyx state. It already sets isLoading: true optimistically, clears it on success/failure, and writes the success message on success (https://github.com/Expensify/App/blob/main/src/libs/actions/Session/index.ts#L1222-L1269). Once the user is returned to the sign-in root, the existing sign-in UI can surface the unlink success message from account.message (https://github.com/Expensify/App/blob/main/src/pages/signin/LoginForm/BaseLoginForm.tsx#L66-L66 and https://github.com/Expensify/App/blob/main/src/pages/signin/LoginForm/BaseLoginForm.tsx#L284-L291) and any server-provided account errors through the existing sign-in/unlink form error rendering (https://github.com/Expensify/App/blob/main/src/pages/signin/UnlinkLoginForm.tsx#L44-L58).

What alternative solutions did you explore? (Optional)

I also considered rendering success/error UI directly inside UnlinkLoginPage, but that would duplicate the sign-in page’s existing message/error handling and still leave the consumed /u/... deep-link route in the stack. A deterministic reset/replace to the public sign-in root fixes the navigation source of truth and reuses the existing UI.

[abbasifaizan70]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-20 16:49:57 UTC.

Proposal (updated)

Updating my proposal to address @Pujan92's point: resetting to the sign-in page fixes the spinner but does not surface the unlink success/error message, because BaseLoginForm clears account messages on mount. This version keeps the flow off the infinite loader and reliably shows the message.

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

Opening the "Unlink Validation" email link lands the user on an infinite full-screen spinner. There are actually two failures to solve: (1) the page never leaves the loader, and (2) the required unlink success (or error) message is never shown.

What is the root cause of that problem?

1 — Infinite spinner. The email link opens u/:accountID/:validateCode in a fresh tab, where UNLINK_LOGIN is the only route in the public stack. UnlinkLoginPage renders only FullScreenLoadingIndicator and, on completion, exits via Navigation.goBack() — which no-ops when canGoBack() is false (Navigation.ts:528-531). So the loader is never replaced.

2 — Message never shows (this is why the reset-only proposals don't work). Every current proposal, mine included, fixes (1) by resetting to TAB_NAVIGATOR (SignInPage). But that does not satisfy the "show success/error message" requirement, because BaseLoginForm clears account messages the moment it mounts/focuses:

// src/pages/signin/LoginForm/BaseLoginForm.tsx:163-170
if (isFocused && isVisible) {
    clearAccountMessages();
}

// src/libs/actions/Session/index.ts:1104
function clearAccountMessages() {
    Onyx.merge(ONYXKEYS.ACCOUNT, {success: '', errors: null, message: null, isLoading: false});
}

So the instant the reset lands on SignInPage, account.message (unlinkLoginForm.successfullyUnlinkedLogin) and account.errors are nulled — the very values the reset was meant to surface. The sign-in page is designed to clear stale account messages on focus, so account.message cannot survive a reset onto it. Any fix that depends on SignInPage/BaseLoginForm to render the unlink result hits this wall.

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

Show the terminal result on UnlinkLoginPage itself instead of depending on goBack()/SignInPage. UnlinkLoginPage never calls clearAccountMessages, so the message persists there. This fixes both failures in one page-local change and touches no shared navigation or sign-in code.

In UnlinkLoginPage, render the loader only while the request is in flight; once it completes, render the success message / errors (reusing the exact DotIndicatorMessage pattern from UnlinkLoginForm), plus a user-initiated "Back to sign in" action:

const [isComplete, setIsComplete] = useState(false);

useEffect(() => {
    if (prevIsLoading && !account?.isLoading) {
        setIsComplete(true);
    }
}, [prevIsLoading, account?.isLoading]);

if (!isComplete) {
    return <FullScreenLoadingIndicator reasonAttributes={{context: 'UnlinkLoginPage'}} />;
}

// Success (account.message) or error (account.errors), same rendering UnlinkLoginForm already uses.
// "Back to sign in" calls redirectToSignIn() — user-initiated only (it clears ACCOUNT).

Why this is the lowest-risk option:

• Single file. No navigator reset, no canGoBack dependency, and nothing touching the shared clearAccountMessages / sign-in flow used by every other login path.
• Message is guaranteed to render, because the page that holds it never clears it — directly satisfying both of @Pujan92's points (land off the loader and show the message).
• Both paths covered. unlinkLogin sets isLoading:false on success and failure, so isComplete flips either way; success shows the banner, error shows account.errors.

What specific scenarios should we cover in tests?

• Fresh email-link tab, request succeeds → loader is replaced by the "Secondary login successfully unlinked!" message (not a spinner, not a blank sign-in page).
• Request fails (expired/invalid code) → error is shown instead of hanging.
• "Back to sign in" returns the user to SignInPage.

What alternative solutions did you explore?

• @Pujan92's literal suggestion — reset to TAB_NAVIGATOR and show the message in SignInPage → BaseLoginForm. This is the natural direction, but making it work requires stopping BaseLoginForm's mount/focus clearAccountMessages() from wiping the unlink message — a change to shared sign-in code exercised by every login flow, so materially higher blast radius than a page-local render. Rendering on UnlinkLoginPage avoids the conflict entirely.
• Reset-to-SignInPage only (my previous version and the other proposals). Fixes the spinner but fails the message requirement for the reason above.
• Navigation.goBack(ROUTES.HOME). HOME resolves against the authenticated stack; unreliable from the public route and leaves the consumed /u/... route in history.

(Optional hardening, out of scope: add a short watchdog timeout so a genuine 407/reauth stall — where failureData can be discarded — also lands on the terminal state instead of the loader.)

[lorretheboy]

Proposal

What is the root cause of that problem?

The unlink email link opens /u/:accountID/:validateCode in a fresh tab. For deep links that land on a public screen, the adapted navigation state is intentionally left as-is, so UNLINK_LOGIN is the only route in the root stack:

App/src/libs/Navigation/helpers/getAdaptedStateFromPath.ts

Lines 379 to 385 in df847ed

	// Public screens (e.g. ValidateLogin) exist in both PublicScreens and AuthScreens navigators.
	// Don't prepend TabNavigator because when the user is unauthenticated, PublicScreens is active
	// and TabNavigator doesn't exist — causing the RESET action to fail.
	const hasOnlyPublicScreens = currentState.routes.every((route) => PUBLIC_SCREENS.has(route.name));
	if (hasOnlyPublicScreens) {
	return currentState;
	}

UnlinkLoginPage renders only a full-screen spinner and, once the UnlinkLogin request finishes (account.isLoading flips back to false), tries to leave with Navigation.goBack():

App/src/pages/UnlinkLoginPage.tsx

Lines 34 to 41 in df847ed

	useEffect(() => {
	// Only navigate when the unlink login request is completed
	if (!prevIsLoading || account?.isLoading) {
	return;
	}
	Navigation.goBack();
	}, [prevIsLoading, account?.isLoading]);

But with a single route in the stack, canGoBack() is false, so goBack just logs "Unable to go back" and returns without navigating:

App/src/libs/Navigation/Navigation.ts

Lines 528 to 531 in df847ed

	if (!backToRoute && !shouldPopToSidebar && !navigationRef.current?.canGoBack()) {
	Log.hmmm('[Navigation] Unable to go back');
	return;
	}

So the user never reaches the sign-in page (which is what displays the unlinkLoginForm.successfullyUnlinkedLogin message from account.message), and the loading indicator stays up forever. The API call actually succeeds — only the navigation away from the spinner silently no-ops.

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

In the navigation effect of UnlinkLoginPage, don't rely on goBack(). Instead, send the user to the sign-in page the same way ValidateLoginPage already does for the exact same situation ("navigate/goBack no-op from the public route, so reset the stack to TAB_NAVIGATOR, which hosts the public SignInPage"):

App/src/pages/ValidateLoginPage/index.web.tsx

Lines 119 to 130 in df847ed

	if (canCompleteTwoFactorOnSignIn) {
	// Surface the sign-in page so its ValidateCodeForm renders the authenticator-code stage. navigate/goBack
	// no-op from the public /v/ route, so reset the stack to TAB_NAVIGATOR (which hosts the public SignInPage).
	// The "2FA required" modal stays rendered as the fallback so a failed hand-off shows it, not a blank screen.
	Navigation.isNavigationReady().then(() => {
	// Bail if the effect re-ran (e.g. `isSignedIn` flipped true) before this resolved, so a
	// stale callback can't reset the stack out from under the new state.
	if (ignore) {
	return;
	}
	navigationRef.reset({index: 0, routes: [{name: NAVIGATORS.TAB_NAVIGATOR}]});
	});

i.e. replace Navigation.goBack() with:

Navigation.isNavigationReady().then(() => {
    navigationRef.reset({index: 0, routes: [{name: NAVIGATORS.TAB_NAVIGATOR}]});
});

The sign-in page then shows the "successfully unlinked" success message via account.message (rendered by BaseLoginForm / UnlinkLoginForm), which is the expected end state of this flow.

What alternative solutions did you explore? (Optional)

Keep Navigation.goBack() for the case where the page was reached from an in-app stack, and only fall back to the TAB_NAVIGATOR reset when navigationRef.current?.canGoBack() is false. Works too, but since this page is practically only ever reached via the email deep link, the unconditional reset is simpler.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-14 14:23:53 UTC.

Proposal (updated)

Update note: @Pujan92 is right that the navigation reset alone does not show the message — the earlier version of this proposal claimed it would, and that was wrong. Below is the verified reason, plus one correction to the direction the thread has taken on the error path.

What is the root cause of that problem?

Three independent gaps. The first is agreed by every proposal here; the second and third are not.

1. The exit no-ops on a fresh email tab (the infinite spinner).

UnlinkLoginPage renders FullScreenLoadingIndicator unconditionally and exits only via a bare Navigation.goBack() once account.isLoading goes true → false. UNLINK_LOGIN is deliberately a standalone public screen that gets no TAB_NAVIGATOR prepended underneath (getAdaptedStateFromPath.ts#L46-L53), so in a tab opened from the email the root stack holds exactly one route, canGoBack() is false, and goBack() hits its guard and returns without navigating (Navigation.ts#L528-L531). Nothing else can unmount the page. This is also why the report is web-only: a native deep link pushes onto the running app's existing stack, so the pop works.

2. Success: BaseLoginForm's mount effect wipes the message before it can render.

successData writes account.message and clears credentials.login (Session/index.ts#L1240-L1255). Empty login means hasLogin is false, so shouldShowLoginForm is true and BaseLoginForm is the form that renders.

But BaseLoginForm's mount-only effect calls clearAccountMessages() under exactly the isFocused && isVisible condition that now holds:

App/src/pages/signin/LoginForm/BaseLoginForm.tsx

Lines 163 to 182 in 1cf3bdb

	useEffect(() => {
	// Call clearAccountMessages on the login page (home route).
	// When the user is in the transition route and not yet authenticated, this component will also be mounted,
	// resetting account.isLoading will cause the app to briefly display the session expiration page.
	if (isFocused && isVisible) {
	clearAccountMessages();
	}
	if (!canFocusInputOnScreenFocus() || !input.current || !isVisible || !isFocused) {
	return;
	}
	let focusTimeout: NodeJS.Timeout;
	if (isInNarrowPaneModal) {
	focusTimeout = setTimeout(() => input.current?.focus(), CONST.ANIMATED_TRANSITION);
	} else {
	input.current.focus();
	}
	return () => clearTimeout(focusTimeout);
	// eslint-disable-next-line react-hooks/exhaustive-deps -- we just want to call this function when component is mounted
	}, []);

and clearAccountMessages merges message: null, errors: null. On the fresh-tab path BaseLoginForm mounts for the first time only after the unlink settles, so the message is destroyed before the render at #L285-L291 can show it. It survives today only on the native path, where the form was already mounted underneath and that effect had run long before — which is exactly why "reset the stack" looks correct on native and still shows nothing on web.

(For the record: the clear is not limited to text input. The handler at #L107-L114 is a second, separate call; the mount effect above is the one that breaks this flow.)

3. Failure: failureData writes no error at all — and that is the only thing missing on that path.

failureData only flips isLoading, so there is nothing in account.errors for any page to render. The "an error should be shown" expectation in this issue is unreachable by construction today.

Correction to the thread — the failure path does not need credentials.login cleared, and clearing it is harmful. It has been suggested that optimisticData wipes the account so isUnvalidatedSecondaryLogin becomes false and no form renders the error. That is not what happens: DEFAULT_ACCOUNT_DATA is only {errors: null, success: '', isLoading: false} and it is applied with Onyx.METHOD.MERGE, so primaryLogin, validated and accountExists all survive. On failure credentials.login is still the secondary login and primaryLogin is still set, so isPrimaryLogin is false, isUnvalidatedSecondaryLogin stays true, and shouldShowUnlinkLoginForm renders UnlinkLoginForm.

That is the correct destination for a failed unlink, and it already does the right thing:

• it already renders account.errors via DotIndicatorMessage + getErrorsWithTranslationData (UnlinkLoginForm.tsx#L53-L59), and
• it has no mount-clear effect, so gap 2 does not apply to it.

So the failure path needs one change only: write the error. Clearing credentials.login in failureData would force shouldShowLoginForm and drop the user on the plain sign-in form, losing the "resend from your primary account / unlink" affordance right when the unlink just failed — a regression, not a fix.

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

Three small changes, one per gap.

1. src/pages/UnlinkLoginPage.tsx — reset the stack when there is nothing to pop. Same pattern ValidateLoginPage already uses for this exact situation, including its ignore guard against a stale async callback (index.web.tsx#L117-L130):

useEffect(() => {
    // Only navigate when the unlink login request is completed
    if (!prevIsLoading || account?.isLoading) {
        return;
    }

    if (navigationRef.current?.canGoBack()) {
        Navigation.goBack();
        return;
    }

    // A tab opened from the unlink email has UNLINK_LOGIN as its only public root route, so bare goBack()
    // no-ops and this loader never unmounts. Reset to TAB_NAVIGATOR (which hosts the public SignInPage) so
    // the unlink result renders.
    let ignore = false;
    Navigation.isNavigationReady().then(() => {
        // Bail if the effect re-ran before this resolved, so a stale callback can't reset the stack
        // out from under the new state.
        if (ignore) {
            return;
        }
        navigationRef.reset({index: 0, routes: [{name: NAVIGATORS.TAB_NAVIGATOR}]});
    });
    return () => {
        ignore = true;
    };
}, [prevIsLoading, account?.isLoading]);

The canGoBack() branch keeps the existing, working native/pushed-stack behaviour byte-for-byte.

2. src/pages/signin/LoginForm/BaseLoginForm.tsx — don't wipe the unlink result on the mount that has to display it.

// UnlinkLoginPage resets the stack to the sign-in page as soon as the unlink settles, so this mount is
// the one that has to render the result. unlinkLogin has just written the whole account object, so there
// is no stale state here for clearAccountMessages to clean up.
const hasJustUnlinkedLogin = account?.message === 'unlinkLoginForm.successfullyUnlinkedLogin';

if (isFocused && isVisible && !hasJustUnlinkedLogin) {
    clearAccountMessages();
}

Skipping the clear is provably safe in this one case rather than merely convenient: optimisticData set {errors: null, success: '', isLoading: true} and successData set {isLoading: false, message}, so the account state on arrival is already byte-for-byte what clearAccountMessages() would produce, except for the message we want to keep. There is precedent for keying on this exact message value one line away, at #L66.

The guard deliberately does not test account.errors. Widening it to skip on any error would strand a stale error from an earlier failed sign-in attempt on the page. And matching a specific unlink error by value cannot work at all: getMicroSecondOnyxErrorWithTranslationKey stores the translated string as the value (translateLocal(error)), so a check like Object.values(account?.errors ?? {}).includes('unlinkLoginForm.unlinkError') compares translated text against a raw translation key and never matches — the error would be wiped on mount anyway. None of this is needed, because the failure path never reaches BaseLoginForm (root cause 3): it lands on UnlinkLoginForm, which has no mount clear.

3. src/libs/actions/Session/index.ts — give the failure path an error to show.

const failureData: Array<OnyxUpdate<typeof ONYXKEYS.ACCOUNT>> = [
    {
        onyxMethod: Onyx.METHOD.MERGE,
        key: ONYXKEYS.ACCOUNT,
        value: {
            isLoading: false,
            errors: ErrorUtils.getMicroSecondOnyxErrorWithTranslationKey('unlinkLoginForm.unlinkError'),
        },
    },
];

ErrorUtils is already imported in this file and getMicroSecondOnyxErrorWithTranslationKey is already used for the sibling loginForm.cannotGetAccountDetails case (#L599). Add a unlinkLoginForm.unlinkError string next to the existing unlinkLoginForm keys in en.ts and es.ts (and the remaining src/languages/*.ts). If the backend also returns onyxData errors for UnlinkLogin, they merge into the same key and render through the same path.

Net result. Success → the tab resets to the sign-in page and BaseLoginForm shows the already-translated "Secondary login successfully unlinked!". Failure → the same reset lands on UnlinkLoginForm, which shows the new error through the error rendering it already has, with the unlink/resend affordance intact. Neither path can hang on the spinner. No new message UI is introduced, and unlinkLogin's success behaviour is untouched.

What alternative solutions did you explore? (Optional)

1. A one-shot RAM flag set by UnlinkLoginPage and consumed by BaseLoginForm's mount effect, instead of keying on the message value. More explicit, and there is precedent for a RAM-only navigation-handoff flag in SignInPage (isAuthenticatingWithShortLivedToken, #L115-L123). I did not lead with it because once gap 3 is fixed at the source, only the success message ever needs preserving, and a single value check does that without adding cross-module state. Happy to switch if reviewers prefer the explicit flag.
2. Re-writing the message from UnlinkLoginPage after the reset. Races the mount clear, with the winner depending on Onyx merge timing — fragile, rejected.
3. Clearing credentials.login in failureData so BaseLoginForm renders the error. Rejected for the reason in root cause 3: UnlinkLoginForm is the correct destination after a failed unlink and already renders account.errors; forcing the login form throws away the recovery affordance.
4. Rendering success/error inside UnlinkLoginPage itself and never navigating. Works, but duplicates message UI that BaseLoginForm / UnlinkLoginForm already own, leaves the spent /u/... URL in history, and contradicts the "navigate, then show the message" direction in @Pujan92's comment.
5. Navigation.goBack(ROUTES.HOME) / Navigation.navigate(ROUTES.HOME, {forceReplace: true}). ROUTES.HOME resolves against the authenticated tab structure while the public navigator registers SignInPage under TAB_NAVIGATOR with no path of its own; the codebase already concluded that navigate/goBack no-op from the public /v/ route and moved ValidateLoginPage to navigationRef.reset. goBack(ROUTES.ROOT) fails too — ROUTES.ROOT is '' and goBack tests it by truthiness, reaching the same canGoBack() === false no-op.
6. Removing UNLINK_LOGIN from the public-screens set so a TAB_NAVIGATOR is prepended and goBack() pops to it. Touches shared deep-link state adaptation for every public screen and risks regressing the other routes in that set; the page-local fix is strictly safer.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-14 14:23:22 UTC.

Proposal

What is the root cause of that problem?

Clicking the unlink link from the email opens UnlinkLoginPage as a fresh navigation entry (new tab / direct deep link), so this screen is the only entry in the navigation stack. On mount the page fires unlinkLogin(), and once the request settles it dismisses itself with Navigation.goBack():

App/src/pages/UnlinkLoginPage.tsx

Lines 34 to 41 in 89bfa7e

	useEffect(() => {
	// Only navigate when the unlink login request is completed
	if (!prevIsLoading || account?.isLoading) {
	return;
	}
	Navigation.goBack();
	}, [prevIsLoading, account?.isLoading]);

The problem is that a bare Navigation.goBack() (no backToRoute) bails out when there is nothing to pop:

App/src/libs/Navigation/Navigation.ts

Lines 528 to 530 in 89bfa7e

	if (!backToRoute && !shouldPopToSidebar && !navigationRef.current?.canGoBack()) {
	Log.hmmm('[Navigation] Unable to go back');
	return;

Because the unlink page is the first and only screen in the stack when it's opened directly from the email, navigationRef.current?.canGoBack() is false, so goBack() logs "Unable to go back" and returns without navigating anywhere. The unlinkLogin request has already finished (isLoading is back to false), but the screen is never dismissed, so the FullScreenLoadingIndicator it renders stays mounted forever — the infinite loading page.

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

Give goBack an explicit fallback route so it navigates even when there is no history to pop. In UnlinkLoginPage:

Navigation.goBack(ROUTES.HOME);

When backToRoute is passed, goBack skips the canGoBack() early return and routes up to the target. For an unauthenticated user ROUTES.HOME resolves to the sign-in page, which already renders the "Secondary login successfully unlinked!" message (or the error) from UnlinkLoginForm, so the user ends up exactly where they should instead of on a stuck spinner. We just need to import ROUTES from @src/ROUTES in the page.

What alternative solutions did you explore? (Optional)

We could keep the bare Navigation.goBack() and add a branch that falls back to Navigation.navigate(ROUTES.HOME) only when canGoBack() is false. That reaches the same result with more code, so passing the fallback route directly is simpler.

Alternatively we could convert UNLINK_LOGIN to makeRequestWithSideEffects and redirect from the resolved response (the way the 2FA validate flow does). But navigation here is already Onyx-driven and works fine when there is history, so the minimal fix is just supplying the fallback route.

[melvin-bot]

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

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-20 17:54:43 UTC.

Proposal

What is the root cause of that problem?

UnlinkLoginPage calls unlinkLogin() on mount, always renders a full-screen loader, and tries to leave only after account.isLoading changes from true to false. At that point it calls bare Navigation.goBack().

App/src/pages/UnlinkLoginPage.tsx

Lines 22 to 46 in 6a1f1a3

	function UnlinkLoginPage({route}: UnlinkLoginPageProps) {
	const accountID = route.params.accountID ?? CONST.DEFAULT_NUMBER_ID;
	const validateCode = route.params.validateCode ?? '';
	const [account] = useOnyx(ONYXKEYS.ACCOUNT);
	const prevIsLoading = usePrevious(!!account?.isLoading);
	useEffect(() => {
	unlinkLogin(Number(accountID), validateCode);
	// We only want this to run on mount
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, []);
	useEffect(() => {
	// Only navigate when the unlink login request is completed
	if (!prevIsLoading || account?.isLoading) {
	return;
	}
	Navigation.goBack();
	}, [prevIsLoading, account?.isLoading]);
	const reasonAttributes: SkeletonSpanReasonAttributes = {
	context: 'UnlinkLoginPage',
	};
	return <FullScreenLoadingIndicator reasonAttributes={reasonAttributes} />;

The request lifecycle is completing. The reproduction logs in the thread show the full false -> true -> false loading transition, followed by canGoBack=false, a root state containing only UnlinkLogin, and a settled backend validation error in Onyx.

#96073 (comment)

This happens because /u/:accountID/:validateCode is a standalone public deep link. UNLINK_LOGIN is included in PUBLIC_SCREENS, and getAdaptedStateFromPath() deliberately returns an all-public state without prepending TAB_NAVIGATOR. A fresh email-link tab therefore has no underlying route to pop.

App/src/libs/Navigation/helpers/getAdaptedStateFromPath.ts

Lines 39 to 53 in 6a1f1a3

	/**
	* Standalone full-screen public pages registered in PublicScreens (unauthenticated navigator) that
	* should NOT have TabNavigator prepended — they render on their own, with no tab navigator underneath.
	*
	* Keep in sync with the screens registered in PublicScreens.tsx (excluding TAB_NAVIGATOR, which hosts
	* the SignInPage at the root, and the other navigator entries).
	*/
	const PUBLIC_SCREENS = new Set<string>([
	SCREENS.VALIDATE_LOGIN,
	SCREENS.TRANSITION_BETWEEN_APPS,
	SCREENS.CONNECTION_COMPLETE,
	SCREENS.BANK_CONNECTION_COMPLETE,
	SCREENS.UNLINK_LOGIN,
	SCREENS.SAML_SIGN_IN,
	]);

App/src/libs/Navigation/helpers/getAdaptedStateFromPath.ts

Lines 379 to 385 in 6a1f1a3

	// Public screens (e.g. ValidateLogin) exist in both PublicScreens and AuthScreens navigators.
	// Don't prepend TabNavigator because when the user is unauthenticated, PublicScreens is active
	// and TabNavigator doesn't exist — causing the RESET action to fail.
	const hasOnlyPublicScreens = currentState.routes.every((route) => PUBLIC_SCREENS.has(route.name));
	if (hasOnlyPublicScreens) {
	return currentState;
	}

Navigation.goBack() explicitly returns without navigating when no fallback is supplied and canGoBack() is false. Since UnlinkLoginPage can render only its loader, the completed page remains mounted indefinitely.

App/src/libs/Navigation/Navigation.ts

Lines 518 to 552 in 6a1f1a3

	function goBack(backToRoute?: Route, options?: GoBackOptions) {
	clearSelectedText();
	if (!canNavigate('goBack', {backToRoute})) {
	return;
	}
	const runImmediately = !options?.waitForTransition;
	TransitionTracker.runAfterTransitions({
	callback: () => {
	if (!backToRoute && !shouldPopToSidebar && !navigationRef.current?.canGoBack()) {
	Log.hmmm('[Navigation] Unable to go back');
	return;
	}
	popAndRealignMfaMarker(
	() => {
	if (backToRoute) {
	goUp(backToRoute, options);
	} else if (shouldPopToSidebar) {
	popToSidebar();
	} else {
	navigationRef.current?.goBack();
	}
	},
	(callback) => TransitionTracker.runAfterTransitions({callback, waitForUpcomingTransition: true}),
	);
	if (options?.afterTransition) {
	TransitionTracker.runAfterTransitions({callback: options.afterTransition, waitForUpcomingTransition: true});
	}
	},
	runImmediately,
	});
	}

Resetting the stack fixes the spinner, but it is not sufficient to show the result:

• On success, unlinkLogin() writes unlinkLoginForm.successfullyUnlinkedLogin and clears credentials.login, so the reset makes BaseLoginForm visible. However, its mount effect immediately calls clearAccountMessages(), which clears that message before it can remain visible.
• On failure, the backend error is applied through response onyxData, while the current failureData only clears isLoading and retains credentials.login. After the reset, this does not reliably select BaseLoginForm, so the settled error can still have no visible result surface. Response Onyx data is applied before failureData, so the existing backend error should be preserved rather than replaced with a generic client error.

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

Lines 1230 to 1277 in 6a1f1a3

	function unlinkLogin(accountID: number, validateCode: string) {
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.ACCOUNT>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.ACCOUNT,
	value: {
	...CONST.DEFAULT_ACCOUNT_DATA,
	isLoading: true,
	},
	},
	];
	const successData: Array<OnyxUpdate<typeof ONYXKEYS.ACCOUNT | typeof ONYXKEYS.CREDENTIALS>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.ACCOUNT,
	value: {
	isLoading: false,
	message: 'unlinkLoginForm.successfullyUnlinkedLogin',
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.CREDENTIALS,
	value: {
	login: '',
	},
	},
	];
	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.ACCOUNT>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.ACCOUNT,
	value: {
	isLoading: false,
	},
	},
	];
	const params: UnlinkLoginParams = {
	accountID,
	validateCode,
	};
	API.write(WRITE_COMMANDS.UNLINK_LOGIN, params, {
	optimisticData,
	successData,
	failureData,
	});

App/src/pages/signin/LoginForm/BaseLoginForm.tsx

Lines 163 to 182 in 6a1f1a3

	useEffect(() => {
	// Call clearAccountMessages on the login page (home route).
	// When the user is in the transition route and not yet authenticated, this component will also be mounted,
	// resetting account.isLoading will cause the app to briefly display the session expiration page.
	if (isFocused && isVisible) {
	clearAccountMessages();
	}
	if (!canFocusInputOnScreenFocus() || !input.current || !isVisible || !isFocused) {
	return;
	}
	let focusTimeout: NodeJS.Timeout;
	if (isInNarrowPaneModal) {
	focusTimeout = setTimeout(() => input.current?.focus(), CONST.ANIMATED_TRANSITION);
	} else {
	input.current.focus();
	}
	return () => clearTimeout(focusTimeout);
	// eslint-disable-next-line react-hooks/exhaustive-deps -- we just want to call this function when component is mounted
	}, []);

App/src/libs/actions/OnyxUpdates.ts

Lines 41 to 69 in 6a1f1a3

	// First apply any onyx data updates that are being sent back from the API. We wait for this to complete and then
	// apply successData or failureData. This ensures that we do not update any pending, loading, or other UI states contained
	// in successData/failureData until after the component has received and API data.
	const onyxDataUpdatePromise = response.onyxData ? updateHandler(response.onyxData) : Promise.resolve();
	return onyxDataUpdatePromise
	.then(() => {
	// Handle the request's success/failure data (client-side data)
	if (response.jsonCode === 200 && request.successData) {
	return updateHandler(request.successData);
	}
	if (response.jsonCode !== 200 && request.failureData) {
	// 460 jsonCode in Expensify world means "admin required".
	// Typically, this would only happen if a user attempts an API command that requires policy admin access when they aren't an admin.
	// In this case, we don't want to apply failureData because it will likely result in a RedBrickRoad error on a policy field which is not accessible.
	// Meaning that there's a red dot you can't dismiss.
	if (response.jsonCode === 460) {
	Log.info('[OnyxUpdateManager] Received 460 status code, not applying failure data');
	return Promise.resolve();
	}
	trackExpenseApiError({
	command: request.command,
	jsonCode: response.jsonCode ?? 0,
	message: response.message,
	requestData: request.data,
	});
	return updateHandler(request.failureData);

Git history explains the regression. PR #36850 changed this completion path from explicit navigation to goBack(), which worked while a sign-in route existed underneath. PR #89295 later made public deep links standalone, invalidating that assumption. The current public navigator now registers TAB_NAVIGATOR as the public SignInPage, so an explicit reset is the correct modern handoff.

#36850

#89295

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

1. In UnlinkLoginPage, replace bare Navigation.goBack() with the established public-link handoff used by ValidateLoginPage: wait for navigation readiness and reset the root to NAVIGATORS.TAB_NAVIGATOR. Include the same cleanup guard so a readiness promise cannot reset navigation after the effect has been invalidated or the page has unmounted.

App/src/pages/ValidateLoginPage/index.web.tsx

Lines 117 to 130 in 6a1f1a3

	useEffect(() => {
	let ignore = false;
	if (canCompleteTwoFactorOnSignIn) {
	// Surface the sign-in page so its ValidateCodeForm renders the authenticator-code stage. navigate/goBack
	// no-op from the public /v/ route, so reset the stack to TAB_NAVIGATOR (which hosts the public SignInPage).
	// The "2FA required" modal stays rendered as the fallback so a failed hand-off shows it, not a blank screen.
	Navigation.isNavigationReady().then(() => {
	// Bail if the effect re-ran (e.g. `isSignedIn` flipped true) before this resolved, so a
	// stale callback can't reset the stack out from under the new state.
	if (ignore) {
	return;
	}
	navigationRef.reset({index: 0, routes: [{name: NAVIGATORS.TAB_NAVIGATOR}]});
	});

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

Lines 27 to 65 in 6a1f1a3

	function PublicScreens() {
	const rootNavigatorScreenOptions = useRootNavigatorScreenOptions();
	const theme = useTheme();
	const StyleUtils = useStyleUtils();
	return (
	<RootStack.Navigator screenOptions={defaultScreenOptions}>
	{/* SignInPage is registered under TAB_NAVIGATOR (the authenticated top-level navigator name) so the public and auth */}
	{/* root structures match. TAB_NAVIGATOR has no path of its own, so the logged-out URL stays at the root "/". */}
	<RootStack.Screen
	name={NAVIGATORS.TAB_NAVIGATOR}
	options={{
	...defaultScreenOptions,
	// If you want to change this, make sure there aren't any animation bugs when signing out.
	// This was put here to prevent excessive animations when resetting the navigation state in `resetNavigationState`
	animation: Animations.NONE,
	}}
	component={SignInPage}
	/>
	<RootStack.Screen
	name={SCREENS.TRANSITION_BETWEEN_APPS}
	component={LogInWithShortLivedAuthTokenPage}
	/>
	<RootStack.Screen
	name={SCREENS.VALIDATE_LOGIN}
	options={defaultScreenOptions}
	component={ValidateLoginPage}
	/>
	<RootStack.Screen
	name={SCREENS.CONNECTION_COMPLETE}
	component={ConnectionCompletePage}
	/>
	<RootStack.Screen
	name={SCREENS.BANK_CONNECTION_COMPLETE}
	component={ConnectionCompletePage}
	/>
	<RootStack.Screen
	name={SCREENS.UNLINK_LOGIN}
	component={UnlinkLoginPage}
	/>

2. Treat completion as a scoped unlink result for the sign-in flow. Record that result origin in the account state for both successData and failureData. On failure, also clear credentials.login so SignInPage deterministically selects BaseLoginForm, while leaving the backend-provided account.errors intact.

3. In BaseLoginForm's mount effect, skip clearAccountMessages() only for that scoped unlink result. Do not remove the cleanup for ordinary sign-in states. Clear the unlink-result marker together with the message/error when the user types or dismisses the result; the existing input path already calls clearAccountMessages().

BaseLoginForm is the intended destination: it already translates and renders the unlink success message, and it already renders the latest account.errors through FormAlertWithSubmitButton. Reusing the full UnlinkLoginForm as a terminal screen would also render its pre-unlink instructions and Unlink button, and on success its secondary-login text would be empty because the credential has already been cleared.

App/src/pages/signin/LoginForm/BaseLoginForm.tsx

Line 66 in 6a1f1a3

const accountMessage = account?.message === 'unlinkLoginForm.successfullyUnlinkedLogin' ? translate(account.message) : (account?.message ?? '');

App/src/pages/signin/LoginForm/BaseLoginForm.tsx

Lines 221 to 222 in 6a1f1a3

	const serverErrorText = useMemo(() => (account ? getLatestErrorMessage(account) : ''), [account]);
	const shouldShowServerError = !!serverErrorText && !formError;

App/src/pages/signin/LoginForm/BaseLoginForm.tsx

Lines 284 to 311 in 6a1f1a3

	{!!account?.success && <Text style={[styles.formSuccess]}>{account.success}</Text>}
	{(!!closeAccount?.success || !!account?.message) && (
	<DotIndicatorMessage
	style={[styles.mv2]}
	type="success"
	// eslint-disable-next-line @typescript-eslint/naming-convention
	messages={{0: closeAccount?.success ? closeAccount.success : accountMessage}}
	/>
	)}
	{
	// We need to unmount the submit button when the component is not visible so that the Enter button
	// key handler gets unsubscribed
	isVisible && (
	<View
	style={[shouldShowServerError ? {} : styles.mt5]}
	ref={viewRef(submitContainerRef)}
	>
	<FormAlertWithSubmitButton
	buttonText={translate('common.continue')}
	isLoading={account?.isLoading && account?.loadingForm === CONST.FORMS.LOGIN_FORM}
	// `beginSignIn` sets `isLoading` in Onyx the moment it's dispatched, so this `isLoading` shows the spinner immediately on press on its own
	shouldShowLoadingImmediatelyOnPress={false}
	onSubmit={validateAndSubmitForm}
	message={serverErrorText}
	isAlertVisible={shouldShowServerError}
	buttonStyles={[shouldShowServerError ? styles.mt3 : {}]}
	containerStyles={[styles.mh0]}
	sentryLabel={CONST.SENTRY_LABEL.SIGN_IN.CONTINUE}

This produces the intended outcomes:

• Success: the consumed /u/... route is removed and BaseLoginForm shows “Secondary login successfully unlinked!”.
• Failure: the consumed route is removed and the same form shows the backend unlink-validation error.
• A later sign-in attempt clears the preserved result normally, without changing cleanup behavior for unrelated authentication states.

Test coverage should include:

• A cold public state containing only UNLINK_LOGIN, with isLoading driven through true -> false, asserting the exact reset to TAB_NAVIGATOR.
• Unmounting or invalidating the effect before navigation readiness resolves, asserting that no stale reset occurs.
• Success and backend-error outcomes, asserting that BaseLoginForm renders the translated message/error and that the mount effect does not clear it.
• A control case proving ordinary stale account messages/errors are still cleared on a normal BaseLoginForm mount.
• Typing after an unlink result, asserting that the result and its scoped marker are cleared.

What alternative solutions did you explore? (Optional)

I considered Navigation.navigate(ROUTES.HOME, {forceReplace: true}) and Navigation.goBack(ROUTES.ROOT), but this unauthenticated flow specifically needs the public SignInPage, and those alternatives depend on route resolution that has already failed historically. Resetting directly to the public TAB_NAVIGATOR mirrors the established magic-link pattern and removes the consumed route deterministically.

I also considered removing clearAccountMessages() from BaseLoginForm on every mount. That would preserve the unlink result, but it would regress the existing protection against stale sign-in state. A scoped unlink-result guard preserves the required success/error while leaving every unrelated mount unchanged.