iOS - Anonymous user does not land on a public room via link

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.84-0
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/74548899/folder/13176964/41237767/1771052797?sort=%2Bstatus_id
Email or phone of affected tester (no customers): gocemate+buzz19961@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: iphone 11/26.2
App Component: Other

Action Performed:

1. Log out of New Expensify (don't kill the app)
2. Via slack navigate to this public room link - https://staging.new.expensify.com/r/1540486774487195

Expected Result:

User should see room as an anonymous user

Actual Result:

Notification modal and concierge modal appears when user is logged out
Sign in button is cut off
When logged in screen is split - behind Home page is onboarding modal

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7263007_1789717532608.ScreenRecording_09-18-2026_09-14-56_1.mp4

View all open jobs on GitHub

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

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

[melvin-bot]

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

[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.

[melvin-bot]

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

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: Fix: anonymous user first time tapping on sign in button or a thread open public room - "Fix: anonymous user first time tapping on sign in button or a thread open public room" by @nkdengineer (High confidence)
Related Issues: [$250] Public room-anon user first time tapping on sign in button or a thread open public room (the issue PR #99582 was fixing)

Recommendation: REVERT

The new !Navigation.isActiveRoute(deeplinkRoute) guard in openReportFromDeepLink only lets the deep-link navigation run when the app is already on the report route, so on a warm start (app not killed) the navigation to the public room is skipped entirely. The PR is a single 8-line change to one file with no dependent PRs, so a revert is clean; if we prefer to roll forward, the guard just needs to test the route the user moved to instead of the destination route.

Assigned: @nkdengineer (PR author), @abdulrahuman5196 (approving reviewer), @stitesExpensify (approving reviewer) from highest-confidence causing PR only
Labels: No label changes. DeployBlockerCash is kept (App PR caused this, so the App deploy is blocked). DeployBlocker was not present, so nothing was removed.

📋 Detailed Analysis

Evidence

• The repro URL in this report (https://staging.new.expensify.com/r/1540486774487195) is the exact same URL used in PR Fix: anonymous user first time tapping on sign in button or a thread open public room #99582's test steps, so the PR is operating on precisely this flow.
• PR Fix: anonymous user first time tapping on sign in button or a thread open public room #99582 is the only change to src/libs/actions/Link.ts between production and staging for 9.4.84 (git log/compare on production...staging shows just merge commit ec198fd).
• isActiveRoute does not exist in Link.ts on production (0 occurrences) and does on staging. This lines up with "Reproducible in production?: No".
• PR Fix: anonymous user first time tapping on sign in button or a thread open public room #99582's own test steps start with "Logout and force close the app", i.e. only the cold-start path was tested. This report's step 1 is "Log out of New Expensify (don't kill the app)" — the warm-start path, which is the one that breaks. That asymmetry is exactly why this slipped through review and QA.
• The reported modals (notification modal, Concierge modal, onboarding modal behind Home) and the clipped Sign in button are all downstream symptoms of the same single failure: navigation never leaves the logged-out Home screen, so the anonymous session ends up rendering Home instead of the room.

Verification

Affected file: src/libs/actions/Link.ts (openReportFromDeepLink → navigateHandler).

• PR Fix: anonymous user first time tapping on sign in button or a thread open public room #99582 changed files: src/libs/actions/Link.ts — the exact file and function containing the broken guard.
• Offending code (❌): src/libs/actions/Link.ts#L624-L629, with the navigation it suppresses at Link.ts#L648.
• isActiveRoute semantics: src/libs/Navigation/Navigation.ts#L303-L309 — it returns true only when the currently active route equals the argument.
• Warm deep links reach openReportFromDeepLink through the Linking.addEventListener('url') path: src/DeepLinkHandler.tsx#L137-L160.
• React Navigation deliberately does not handle /r/<reportID> for unauthenticated sessions, so openReportFromDeepLink is the only thing that can navigate there: src/libs/Navigation/linkingConfig/subscribe.ts#L61-L67.

Root Cause

navigateHandler exists to navigate the anonymous user to the deep-linked report route. PR #99582 added an early return in front of it:

// Skip if the user already left the deeplinked route.
const deeplinkRoute = route as Route;
if (deeplinkRoute && !Navigation.isActiveRoute(deeplinkRoute)) {
    return;
}

Navigation.isActiveRoute(deeplinkRoute) is true only when the app is already sitting on r/<reportID>. So the guard's polarity is inverted relative to its intent: instead of "bail if the user navigated away", it means "bail unless the navigation would be redundant". The handler can now only ever run when there is nothing left to do.

Why it passes on a cold start but fails warm:

• Cold start (killed app): React Navigation consumes the initial URL via getStateFromPath, so r/<reportID> is already the active route by the time navigateHandler fires. isActiveRoute is true, the guard passes, and the subsequent Navigation.navigate is a harmless no-op. Everything looks fine — which is what the PR's screenshots show.
• Warm start (app still running, per this report's step 1): the URL arrives on the Linking.addEventListener('url') path, and subscribe.ts#L65 explicitly drops report deep links for unauthenticated sessions so that openReportFromDeepLink owns the navigation. The active route is still the logged-out Home screen, so isActiveRoute('r/1540486774487195') is false → early return → no navigation ever happens.

The anonymous session is still created (openReport runs before this, and doneCheckingPublicRoom dismisses the splash), so the app unblocks onto the Home screen instead of the room. That is what produces every reported symptom: the Home screen's notification-permission and Concierge/onboarding modals render over a logged-out Home, the Sign in button is clipped behind them, and the leftover stack shows as a "split screen" with the onboarding modal behind Home once the user signs in.

Note that the intended fix from #96346 (don't yank an anonymous user out of the sign-in modal back into the room) is achievable without breaking this flow — the guard needs to test the route the user moved to, not the destination. There is already an established idiom for exactly that in src/libs/actions/Session/index.ts#L389-L396 and in src/libs/Navigation/AppNavigator/withAgentAccessDenied.tsx#L20-L21.

Roll-forward alternative (if a revert is undesirable because #96346 regresses): replace the destination-route check with a check for where the user actually went, e.g. if (Navigation.isActiveRoute(ROUTES.SIGN_IN_MODAL)) { return; }, or capture the active route when handleDeeplinkNavigation starts and bail only if it changed after we reached the deep-link route.

---

💡 Suggested AI code review rule

This bug looks like a recurring, mechanically detectable pattern, so it may be worth a coding-standards rule so the AI reviewer catches the next one. Proposed for Expensify/App (.claude/skills/app-coding-standards):

• Rule: CONSISTENCY-18 Never gate a navigation on isActiveRoute of its own destination
• Condition: Flag any early return or guard of the form if (!Navigation.isActiveRoute(X)) { return; } (or continue/no-op) that sits in the same function as a Navigation.navigate(X) for the same route X. isActiveRoute(X) is true only when the app is already on X, so such a guard permits the navigation only when it is redundant and suppresses it in every case that matters. Instead, either invert it to the if (!isActiveRoute(X)) { navigate(X); } form (navigate only when not already there), or — when the intent is "abort because the user navigated away" — pass the origin route or the route the user moved to (e.g. ROUTES.SIGN_IN_MODAL), never the destination.
• Why: Silently turns a navigation into dead code on any path where the app isn't already at the destination. Typically invisible in cold-start testing (React Navigation resolves the initial URL first, so the guard happens to pass) and only breaks warm-start/deep-link flows, so it survives review and QA. Caused iOS - Anonymous user does not land on a public room via link — a 9.4.84 deploy blocker where anonymous public-room deep links stopped working entirely.
• Search pattern: rg -U -n '!\s*Navigation\.isActiveRoute\(\s*(\w+)[\s\S]{0,400}?Navigation\.navigate\(\s*\1' — then, for each hit, confirm the guard's body is a bare return/continue rather than the navigation itself. AST form: an IfStatement whose test is UnaryExpression(!, CallExpression Navigation.isActiveRoute(r)) and whose consequent is a bare return, with a Navigation.navigate(r) on the same r later in the enclosing function.
• Offending code (❌): src/libs/actions/Link.ts#L624-L629 (plus the suppressed Link.ts#L648)
• Fix (✅): the existing correct idioms — src/libs/actions/Session/index.ts#L389-L396 (navigate only when not already there) and src/components/ReportActionItem/MoneyRequestReportPreview/index.tsx#L325-L331 (guard on the origin route, navigate elsewhere)

The full rule file, with the ❌/✅ code inline in Expensify/App's app-coding-standards format, would go in Expensify/App itself. If it's worth adding, a maintainer can open it there as a draft PR.