Conversation is not opened when opening conversation link during login

[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: #91796
Email or phone of affected tester (no customers): expensify416+da2@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: macOS chrome
App Component: Chat Report View

Action Performed:

1. Log in to the app
2. Copy a conversation/chat link
3. Log out from the app
4. Paste the link to browser bar
5. Press Enter
6. Log in with the same account you have signed in on step 1

Expected Result:

On finishing login, user should be redirected to the conversation room they have copied the link for on step 2

Actual Result:

User remains on home page

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7165820_1780006268235.Screen_Recording_2026-05-29_at_1.02.27_in_the_morning.mp4

View all open jobs on GitHub

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

[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/2c9cce8852085e216359551d68a06672c40bf3ef5f89f729727bba093f32923f

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #91796

[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

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

After PR #91796 was merged, deep links to chat conversations are silently dropped when the URL arrives during the login flow. The user signs in successfully but is left on the home page instead of being redirected to the linked conversation. This regression affects both this issue and the closely-related deploy blocker #92039 (Concierge deep link after login).

What is the root cause of that problem?

PR #91796 added a new guard at the top of the Linking URL subscriber, intended to prevent an "unhandled NAVIGATE" error when TabNavigator's child router has not yet mounted:

src/libs/Navigation/linkingConfig/subscribe.ts:35-43

const state = navigationRef.current?.getRootState();
if (!isTabNavigatorReady(state)) {
    return;
}
listener(url);

The guard is too aggressive in three ways:

1. It silently drops the URL — there is no queue, retry, or replay. Once listener(url) is skipped, react-navigation never sees the URL again.
2. isTabNavigatorReady is always false on PublicScreens. PublicScreens.tsx declares no TAB_NAVIGATOR route at all, so during the entire login flow the guard discards every URL event (isTabNavigatorReady.ts:10-13).
3. The PR's fallback claim does not hold for authenticated runtime URL events. The PR comment says protected-screen links will be handled by openReportFromDeepLink via waitForProtectedRoutes(). But that function explicitly short-circuits for authenticated users at Link.ts:340-343:

// Navigation for signed users is handled by react-navigation.
if (isAuthenticated) {
    return;
}

So as soon as auth flips true, openReportFromDeepLink delegates back to react-navigation — which is the very listener that just dropped the URL. The two listeners cancel each other out and the URL is lost.

Repro flow (this issue)

1. User pastes the chat URL in the browser bar while on the login screen. Linking emits a 'url' event; the subscribe guard discards it because TAB_NAVIGATOR is not in the public-screen route tree.
2. DeepLinkHandler.tsx:97-106 also receives the event and calls openReportFromDeepLink(url, ..., isCurrentlyAuthenticated=false, ...). This path can handle the case if isAuthenticated is captured as false at call time.
3. The Applause repro is "paste URL → press Enter → log in with the same account." On web, staging.new.expensify.com already has an auth token from a prior session in many cases, so hasAuthToken() returns true at step 2 → openReportFromDeepLink hits the early return at Link.ts:341 and does nothing. The user logs in, but no URL is ever forwarded to react-navigation.
4. There is also a remount race: DeepLinkHandler's listener re-registers whenever its Onyx-status dependencies change around login — if a URL arrives during the teardown/re-register window, only subscribe.ts sees it, and it gets dropped.

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

Replace the silent drop in subscribe.ts with deferral: buffer the URL and replay it once TabNavigator becomes ready.

Concretely, in src/libs/Navigation/linkingConfig/subscribe.ts:

1. When isTabNavigatorReady(state) is false, store the URL in a module-local pendingUrl instead of returning.
2. Register a one-shot navigationRef.addListener('state', ...) that, when the root state first reports isTabNavigatorReady(newState) === true, calls listener(pendingUrl) and clears the buffer.
3. Coalesce on the latest URL (a newer paste replaces an older buffered URL).

This preserves the original intent of the PR (avoid dispatching nested NAVIGATE before the child router is mounted) without losing URLs that arrive during the public-screen → protected-screen transition. It also avoids the remount race in DeepLinkHandler because the URL no longer depends on which listener fires first.

A narrower alternative (less preferred) is to only block URLs whose getAdaptedStateFromPath result targets a nested-TabNavigator screen, letting root-level / RHP-only routes through unconditionally — but the deferred-replay approach is more robust and covers both #92041 and #92039.

What alternative solutions did you explore?

• Revert PR Wait for TabNavigator mount before resolving waitForProtectedRoutes #91796. Would restore deep linking but reintroduces the "unhandled NAVIGATE" console error the PR was fixing. The PR also has the related sibling issue Deeplinks - Concierge chat does not open automatically after login from concierge deeplink #92039, so a buffer-and-replay is preferable to a revert.
• Remove the if (isAuthenticated) return; short-circuit in openReportFromDeepLink and let DeepLinkHandler handle authenticated runtime URLs imperatively. This would also work, but it duplicates navigation logic across two paths and reverses an intentional delegation to react-navigation. Fixing the regression at the site that introduced it (subscribe.ts) is cleaner.

Related issues

• Deeplinks - Concierge chat does not open automatically after login from concierge deeplink #92039 — Same root cause (PR Wait for TabNavigator mount before resolving waitForProtectedRoutes #91796 drops the URL during the login transition). A single fix to subscribe.ts should resolve both deploy blockers.

---

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

[IuliiaHerets]

Not reproducible on Windows 10/Chrome v9.3.89-3

c4365c027e514fd3ddc0b2a9fef93cae.mp4