Agents - New agent RHP opens after refreshing edit photo RHP

[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: 9.4.32-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: #93926
Email or phone of affected tester (no customers): nosdjosdosjosjio1@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Other

Action Performed:

1. Go to staging.new.expensify.com
2. Go to Account > Agents.
3. Click New agent.
4. Click on the avatar.
5. Click Upload photo.
6. Upload a photo.
7. On edit photo page, refresh the page.
8. Click RHP back button.

Expected Result:

In Step 7, edit photo RHP will open after refreshing the page.

Actual Result:

In Step 7, new agent RHP opens after refreshing edit photo RHP.
In Step 8, edit photo RHP is only shown after returning from new agent RHP.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7203717_1783596484370.4.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @jmusial

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

[melvin-bot]

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

[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 (MelvinBot analysis)

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

In the New agent flow, uploading a photo opens the edit-photo (avatar-crop) RHP. Refreshing the page on that RHP re-opens the New agent RHP on top of the edit-photo RHP (reversed order) instead of restoring the edit-photo RHP directly.

What is the root cause of that problem?

Introduced by #93926, which migrated the avatar cropper to the avatar-crop navigation RHP.

The navigation-linking layer actually reconstructs the stack correctly on refresh — base settings/agents/new/avatar (AddAgentAvatarPage) with avatar-crop on top. The reversal comes from a redirect guard on AddAgentAvatarPage that relies on in-memory state wiped by the browser refresh:

• The New-agent avatar flow is gated by an in-memory, non-persisted store — plain module-level let variables at pendingAgentAvatarStore.ts:9-12 (navigationToken, returnRoute, pendingAvatar, initialPresetID).
• The happy path sets the token in AddAgentPage.tsx:82-83 before navigating to the avatar page.
• On refresh, all that in-memory state is reset. AddAgentAvatarPage's mount effect sees consumeNavigationToken() === false and fires Navigation.navigate(returnRoute) → AddAgentAvatarPage.tsx:17-27, where returnRoute falls back to settings/agents/new. That pushes the New-agent RHP on top of the already-restored avatar-crop RHP — exactly the observed reversed order.

Note: because this store is in-memory, the in-progress New-agent draft (pending avatar / preset) is lost on any refresh regardless — so the reported "expected result" isn't fully recoverable without persisting that state.

Evidence chain

1. avatar-crop opens at {base}/avatar-crop = settings/agents/new/avatar/avatar-crop (useAvatarCrop.ts:48,56 via createDynamicRoute).
2. On refresh, getAdaptedStateFromPath strips the avatar-crop suffix, validates SETTINGS.AGENTS.ADD_AVATAR against AVATAR_CROP.entryScreens (ROUTES.ts:210-223), and getDynamicRouteAdaptedState → insertStateBelow correctly places avatar-crop on top (matches the cross-modal-stack case in tests/navigation/getDynamicRouteAdaptedStateTests.ts).
3. After mount, AddAgentAvatarPage's effect redirects to returnRoute, re-pushing the New-agent RHP above it.

• Confidence: High (code trace; the linking layer is verified correct, the redirect is the deterministic cause). Not runtime-confirmed via Jest/browser, but the path is unambiguous.

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

The mount guard in AddAgentAvatarPage.tsx:17-27 must tolerate a cold reload where avatar-crop sits on top. Options, roughly in order of preference:

1. Fully dismiss instead of push. When the token is absent, dismiss the whole nested RHP (including the stacked avatar-crop) back to settings/agents/new rather than Navigation.navigate(returnRoute), which stacks on top. This lands the user cleanly on the New-agent RHP with no reversed order.
2. Skip the redirect when a child avatar-crop route is active on top of this screen (detect it from nav state), so the guard doesn't fight the restored stack.
3. Persist the guard/return-route (and ideally the pending-avatar draft) in Onyx so a refresh keeps context and the edit-photo RHP restores as the reporter expects — heavier, but the only option that makes the flow actually survive a refresh.

Given this is a deploy blocker from a single PR, reverting #93926 is also a valid fast path if a clean fix can't land quickly.

What alternative solutions did you explore?

Considered a navigation-linking / entryScreens ordering bug, but ruled it out — the linking layer reconstructs avatar-crop-on-top correctly (confirmed by code trace and existing getDynamicRouteAdaptedStateTests.ts). The defect is specifically the in-memory redirect guard on AddAgentAvatarPage.

---

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

[parasharrajat]

I checked this during the PR testing and on staging. If you refresh the add agent page, it opens a new RHP for a new agent over the old one. So it is not a regression from our PR specifically.

Root cause was already present on staging which Causes duplicate New agent page on refresh.