Email- Endless loading instead redirect to the workspace chat when user click invite link

[applause-bot]

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.89-1
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176726/test-cases/41237087
Email or phone of affected tester (no customers): lattelover1412+290516@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: android
App Component: Other

Action Performed:

Setup - Can be executed in a Secondary device or browser

1. Log in as an admin of a workspace or create one
2. Enter a custom name for the workspace
3. In the workspace Settings, click on Members
4. Click on the Invite Member button
5. Add an email address that does not have an Expensify account
6. Click Invite (Should be a real account with an inbox that can receive the invite)

In the Main Testing Device (ensure the app is logged out)

1. Open the email inbox
2. Click on the link at the bottom of the email

Expected Result:

User should be directed to app after user click on the link at the bottom of the invited email.

Actual Result:

After click on the link at the bottom of the email, user direct to app but the app is endless loading state

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7165968_1780020652018.Recording__4120.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7165968

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/15a41cf0820c39c60f5fd3b5eecefd58fdba74dc4cf665490bc5dee55ea097fe

[melvin-bot]

Triggered auto assignment to @neil-marcellini (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

What is the root cause of that problem?

The "link at the bottom" of the workspace invite email is a magic-link of the form /v/:accountID/:validateCode?exitTo=workspaces/<policyID>/join?email=<inviterEmail>. On Android it deep‑links into ValidateLoginPage, which calls signInWithValidateCodeAndNavigate(...exitTo) → handleExitToNavigation.

For a brand-new user (no Expensify account yet), the BE response from SignInUserWithLink writes autoAuthState = FAILED and never sets session.authToken. The new handleExitToNavigation awaits waitForUserSignIn() — which only resolves when authToken becomes truthy via the Onyx session callback. For a new user that never happens, so the resolver is held forever and FullScreenLoadingIndicator stays on screen → endless loading.

This regressed in staging because PR #88538 ("[BATCH 2] Migrate Navigation usage, part 1") (in v9.3.89-1, not in production) rewrote handleExitToNavigation from InteractionManager.runAfterInteractions(() => waitForUserSignIn().then(...)) to:

TransitionTracker.runAfterTransitions({
    callback: async () => {
        await waitForUserSignIn();           // <- never resolves for new user
        await Navigation.waitForProtectedRoutes();
        Navigation.goBack(ROUTES.HOME);
        Navigation.navigate(exitTo);
    },
    waitForUpcomingTransition: true,
});

Previously, the ValidateLoginPage autoAuthState === FAILED effect could navigate the user back. Now everything is gated behind a single await waitForUserSignIn() inside the transition callback, with no failure path.

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

Make handleExitToNavigation failure-aware so a FAILED sign-in unblocks the callback instead of waiting forever for an authToken that will never come. Concrete options (in order of preference):

1. Race waitForUserSignIn() against an autoAuthState === FAILED listener. If sign-in fails, abort the goBack/navigate chain and let the existing ValidateLoginPage failure UI take over (it already redirects the user to a usable state, including a code-input prompt for the new account).
2. Alternatively, drop waitForUpcomingTransition: true here — on a cold-start deep-link into the public stack there is no upcoming transition to track, so it just adds the 1s MAX_TRANSITION_START_WAIT_MS gate and obscures the real bug.
3. Add a timeout/cancellation token to waitForUserSignIn() so callers can give up after the sign-in clearly failed (autoAuthState === FAILED).

The fix should also be QA-verified on iOS, since the same code path runs there.

What alternative solutions did you explore?

• Reverting PR #88538 — restores the prior InteractionManager.runAfterInteractions behavior and the ValidateLoginPage FAILED effect can recover the user. Lowest risk for a deploy blocker if a targeted fix can't land quickly.
• Auditing other TransitionTracker.runAfterTransitions(..., { waitForUpcomingTransition: true }) call sites introduced by the same migration for similar "callback awaits something that may never resolve" patterns.

Investigation details & evidence

Symptom: New (non-Expensify) user invited to a workspace → clicks the link at the bottom of the email → Android app opens → endless loading. Reproducible in staging (v9.3.89-1), NOT in production. Reported by Applause TC 41237087.

Affected user (tester): lattelover1412+290516@gmail.com.

Deep-link entry — ValidateLoginPage mounts and starts sign-in, then renders FullScreenLoadingIndicator while waiting: src/pages/ValidateLoginPage/index.tsx:19-50.

The stall site (changed by PR #88538): src/libs/actions/Session/index.ts:1415-1425.

waitForUserSignIn only resolves on a valid authToken: src/libs/actions/Session/index.ts:80-101 and #L1405-L1413.

waitForUpcomingTransition semantics (adds a 1s gate, then needs an actual transition to flush): src/libs/Navigation/TransitionTracker.ts:116-163.

signInWithValidateCode failure branch only writes autoAuthState=FAILED, never sets authToken: src/libs/actions/Session/index.ts:896-970.

Related (different) issue: #90140 (back-arrow → endless loading) suggests the same handleExitToNavigation migration may have other failure modes worth checking together.

Secondary suspect considered: PR #91796 ("Wait for TabNavigator mount before resolving waitForProtectedRoutes") also touches the deep-link gate; ruled out as primary because the stall happens before waitForProtectedRoutes (the waitForUserSignIn() await never completes).

Confidence: High that the stall is in handleExitToNavigation and that PR #88538 introduced it; medium on the exact new-user failure mechanism vs. a related stall in waitForProtectedRoutes — both lead to the same symptom and the same fix surface.

Logs that would confirm: Auth/Web-Expensify logs for SignInUserWithLink calls with the tester email around the v9.3.89-1 deploy window to confirm the non-success jsonCode and Sentry breadcrumbs showing autoAuthState=FAILED written without a subsequent authToken.

---

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