Deeplinks - Concierge chat does not open automatically after login from concierge deeplink

[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/test-runs/TR-35244/folder/13176964/41237739/1447301176?sort=%2Bidentifier
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 10
App Component: Left Hand Navigation (LHN)

Action Performed:

1. Log out of NewDot
2. Go to https://staging.new.expensify.com/concierge
3. Verify that you are taken to the login screen
4. Log in with an existing account
5. Verify you're navigated to the concierge chat after login
   Result: the user is not automatically redirected to the Concierge chat.
6. Click on any of the menu options of LHP, except in "Inbox"
   Result: The user is redirected to "Inbox" and Concierge chat is opened

Expected Result:

After logging in from the Concierge deep link, the user should be automatically redirected to the Concierge chat.

Actual Result:

After logging in, the user is not automatically redirected to the Concierge chat. The redirect only occurs after the user clicks any option in the LHN.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7165964_1780020467198.bandicam_2026-05-28_20-53-58-380.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7165964

[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/e20d910bd59aeafead05d31acd6be2308da8a9ccfc30ca193e6b7bdce0a51943

[melvin-bot]

Triggered auto assignment to @carlosmiceli (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?

After a logged-out user signs in from the /concierge deep link, ConciergePage re-focuses and calls navigateToConciergeChat(..., shouldDismissModal=true, ...). With shouldDismissModal=true and conciergeReportID defined, that helper takes the Navigation.dismissModalWithReport(...) branch.

ConciergePage is rendered as a full-screen route (not inside a side-modal). The dismiss-modal path schedules navigate(reportRoute) inside an afterTransition callback queued by TransitionTracker.runAfterTransitions({callback: afterTransition, waitForUpcomingTransition: true}). Because no modal is actually open at /concierge after login, the DISMISS_MODAL dispatch is effectively a no-op and no transition runs — so the queued navigate to the Concierge report never fires.

The pending callback then fires later when the user triggers any navigation (clicking a non-Inbox LHN item produces a real transition), which both explains the missing auto-redirect after login and the "click anywhere → end up at Inbox with Concierge opened" behavior reported in step 7.

Supporting evidence

• ConciergePage.tsx:33-48 — useFocusEffect post-auth path calls navigateToConciergeChat(..., true, ...).
• Report/index.ts:3934-3940 — when shouldDismissModal is true and conciergeReportID is defined, it calls Navigation.dismissModalWithReport(...) instead of a plain navigate.
• Navigation.ts:834-870 — dismissModalWithReport dispatches dismissModal({afterTransition: navigate(reportRoute)}).
• Navigation.ts:805-825 — dismissModal queues afterTransition behind waitForUpcomingTransition: true; the upcoming transition never starts when there is no modal to dismiss.
• Possibly related: [$250] After signing in with a new account, the home page appears instead of the room #85242 (after sign-in from a /r/<reportID> deep link, the home page opens instead of the room) shows a very similar pattern of post-auth deep-link routing failing.

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

In App/src/pages/ConciergePage.tsx, change the call inside useFocusEffect so the post-login path does not ask for modal dismissal — pass shouldDismissModal=false to navigateToConciergeChat. With shouldDismissModal=false and a valid conciergeReportID, the helper falls through to the plain Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(conciergeReportID), ...) branch, which immediately routes to the Concierge report instead of waiting on a non-existent modal transition.

The shouldDismissModal=true argument is only correct when ConciergePage is opened as part of a modal flow (which is not the case here — this is the standalone web /concierge route).

What alternative solutions did you explore? (Optional)

• Detect at the dismissModalWithReport call site whether a modal is actually open and short-circuit to a plain navigate when there is none. This is a broader fix that helps any other callers that may have the same misuse.
• Add a "pending deep-link" check in openReportFromDeepLink that re-resolves /concierge after waitForUserSignIn() and routes directly to the Concierge report instead of relying on ConciergePage itself to do it.

What I could not confirm

I could not reproduce locally or confirm with production logs (the bug is staging-only and the reporter notes it isn't reproducible in production). A git blame on the recent staging deploy did not surface a touch to ConciergePage.tsx or navigateToConciergeChat, so the regression is most likely an indirect side-effect of a recent change in TransitionTracker / dismiss-modal behavior rather than this page itself. The behavior described (no auto-open + click-anywhere-and-it-opens) is highly consistent with a queued afterTransition callback that is waiting for a transition that never starts.

---

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