[Due for payment 2026-09-30] Agents - Verify account page opens after swiping back three times from View agent history

@marufsharifi

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.57-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #98091
Email or phone of affected tester (no customers): jdkdkkdkdkdkdkd@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 15 Pro Max / iOS 26.6.1
App Component: Other

Action Performed:

Precondition:

Create a new Gmail account. Do not verify the account.
Create an agent on Account > Agents.

Launch Expensify app.
Go to Account > Agents.
Tap on the agent.
Tap Chat with agent.
Tap on the chat header.
Tap View agent history.
Swipe back three times.

Expected Result:

App will return to Agents page.

Actual Result:

Verify account page opens after swiping back three times from View agent history.

Workaround:

Unknown

Platforms:

Screenshots/Videos

Bug7238274_1787232500170.ScreenRecording_08-20-2026_21-22-33_1.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @marufsharifi

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

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

@Julesssss

@Julesssss @marufsharifi you have been assigned to this deploy blocker because you reviewed the offending PR: #98091

👋 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:

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

@hungvu193

@hungvu193 you have been assigned to this deploy blocker because you authored the offending PR: #98091

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

@hungvu193

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #98091 - "Add search this user/agent to ProfilePage" by @hungvu193 (High confidence)
Related Issues: N/A

Recommendation: REVERT

PR #98091 introduced the exact "View agent history" menu item in reproduction step 6, and that new button navigates straight to the top-level Search tab from deep inside the Agents RHP flow, which corrupts the back stack so swiping back lands on the Verify account interstitial instead of the Agents page. The PR is small and self-contained (only ProfilePage.tsx + language files + a test), so it reverts cleanly; a targeted roll-forward fix is also viable if the team prefers to keep the feature (see Root Cause).

Assigned: @hungvu193 (PR author), @marufsharifi and @Julesssss (approving reviewers) from the causing PR — already assigned.
Labels: No change. DeployBlockerCash is correctly retained (App-side fix, App deploy blocked). DeployBlocker was not present, so nothing to remove.

📋 Detailed Analysis

Evidence

The reproduction hinges on tapping "View agent history" (step 6). That menu item, and its profilePage.viewAgentHistory / profilePage.viewUserHistory strings, were added by PR Add search this user/agent to ProfilePage #98091 — before this PR the button did not exist, so this exact flow could not occur. This is consistent with the report ("N/A - new feature, doesn't exist in prod") and staging-only reproducibility.
The button was added to the shared public ProfilePage (src/pages/ProfilePage.tsx), which is what renders when you open a profile from a chat header — matching steps 3–6 (agent profile → Chat with agent → chat header → View agent history).
The button's onPress calls Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute(...)), i.e. it jumps to the top-level Search bottom-tab from inside a deeply nested Agents/RHP modal stack.

Verification

Affected file: src/pages/ProfilePage.tsx. The new menu item is at L339–L352, with the cross-tab navigation at L349:
```
Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute({query, rawQuery: query}));
```
Confirmed PR Add search this user/agent to ProfilePage #98091 modifies this file: gh pr view 98091 --json files lists src/pages/ProfilePage.tsx (+24/-6) plus the 11 src/languages/*.ts files (adding viewUserHistory/viewAgentHistory) and tests/ui/ProfilePageTest.tsx. No navigator/back-behavior files are touched.
Merge timing aligns: PR merged 2026-08-19, first reported on 9.4.57-0 staging on 2026-08-20.

Root Cause

The new entry point navigates from a deeply nested flow (Account > Agents → agent profile → chat → chat header profile → menu item) directly to the top-level SEARCH_ROOT bottom-tab via Navigation.navigate. This switches the active bottom-tab / top-level navigator without unwinding the Agents modal/RHP stack that led there. When the user then swipes back repeatedly, the back stack no longer traces the original Agents path; for an unverified account the app falls through to the "Verify account" interstitial instead of returning to the Agents page.

Note the Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute({query, rawQuery: query})) pattern itself is common and used correctly elsewhere (e.g. src/pages/settings/Subscription/CardSection/CardSection.tsx), so the defect is the interaction between this new entry point's deep nesting + tab switch and the back-navigation/unverified-account guard — not the navigate call in isolation.

Roll-forward alternative (if keeping the feature): dismiss/unwind the current modal stack before switching tabs (e.g. reveal the route before dismissing the modal, or force-replace) so the back stack resolves to a sane origin, and verify the unverified-account path does not surface the Verify account interstitial on back navigation. Because a clean revert is available and this is a brand-new feature, REVERT is the safer choice for unblocking the deploy.

Deploy Blocker #101825 was identified to be related to the PR #99295 that attempted to fix this issue.

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.