[Due for payment 2026-08-08] Rillet- After clicking export option, background changes to Accounting, back button closes RHP

[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.45-2
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: #97164
Email or phone of affected tester (no customers): applausetester+ssndjois2jd1@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Log in with Expensifail account.
• Workspace is connected to Rillet.
• Enable Configure exporting to multiple accounts in Accounting > Export.
• Assign a virtual card to yourself.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Click card link in card assigned system message.
4. Click on the export row.
5. Click export option link.
   BUG 1: Background changes from Inbox to Accounting.
6. Click RHP back button.
   BUG 2: RHP closes instead of returning to Rillet per-card account export RHP.

Expected Result:

BUG 1: Background will not change to Accounting.
BUG 2: RHP will return to Rillet per-card account export RHP.

Actual Result:

BUG 1: Background changes from Inbox to Accounting.
BUG 2: RHP closes instead of returning to Rillet per-card account export RHP.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7219459_1785221422108.13.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @truph01

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

[melvin-bot]

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

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

[melvin-bot]

⚠️ 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.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[MelvinBot]

Deploy Blocker Analysis

Causing PR: #96923 (Rillet per-card export flow) — not #97164, which melvin-bot auto-assigned. Recommendation: targeted fix by the feature owner, do not revert.

Root cause (both bugs): The WORKSPACE_COMPANY_CARD_EXPORT dynamic route is opened with a plain Navigation.navigate(...), and its final navigation state is rebuilt by getStateForDynamicRoute from the route's static hierarchy — which nests the export/Rillet screens under Accounting/Workspace-settings — instead of from the screen the user actually came from.

• BUG 1 (background → Accounting): the rebuilt stack reconstructs the Accounting central-pane page as the RHP background, even though the user started from Inbox → workspace chat → card details.
• BUG 2 (back closes RHP): the rebuilt stack does not contain the RilletCardAccountCardList RHP the user was on (it was reached transiently via navigate, not persisted), so the back button has no in-stack predecessor and dismisses the panel.

Evidence & why #97164 is not the cause

Mechanism:

• Export rows navigate with a plain Navigation.navigate to the export dynamic route: RilletCardAccountCardList.tsx:96
• State is built purely from the static routeNames hierarchy, not the originating screen: getStateForDynamicRoute.ts:60-114
• entryScreens is only used for match validation, not for choosing the underlying screen: getStateFromPath.ts:46-55
• Export + Rillet screens are statically nested under Accounting/Workspace-settings: config.ts:801, config.ts:847

Why #97164 is NOT the cause: it only added one allowed value to the export route's entryScreens array (ROUTES.ts:814-823). entryScreens only gates whether a dynamic-route match is accepted — it has no influence on the reconstructed background or the RHP back stack. It was simply the most recent merge in this feature area, which is why it was auto-assigned.

#96923 created RilletCardAccountCardList.tsx and reworked the WORKSPACE_COMPANY_CARD_EXPORT route (path + entryScreens + getRoute), and is on the current StagingDeployCash (9.4.45-2).

Suggested fix (targeted, no revert)

The export dynamic route needs to preserve the screen it was actually launched from so the RHP background and back target are correct. Two options, in order of preference:

1. Seed the rebuilt stack with the focusedRoute that satisfied the entryScreens match (the Rillet per-card list) rather than only the static routeNames hierarchy, so the background underneath and the back target become the Rillet export list.
2. From RilletCardAccountCardList.tsx:96, navigate with an explicit backTo so goBack returns to POLICY_ACCOUNTING_RILLET_CARD_ACCOUNT_CARD_LIST and the background isn't swapped. This file already computes a backPath for its own header, so the pattern exists locally.

The cleanest fix depends on the intended cross-navigator back behavior, so this is best picked up by the #96923 owner/reviewers (s77rt, lakchote, truph01) rather than a blind revert — especially since #97164 already layered a fix on top of this feature.

Confidence: High that #96923 is the owning PR and navigation-state reconstruction is the mechanism; High that #97164 is not the cause. Medium on the exact fix location.

---

Next Steps: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.