Expense-To field shows correct avatar but wrong name after creating new report on confirm page

[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.0-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/TR-39040/folder/13177049/42645090/1465646483?sort=-identifier
Email or phone of affected tester (no customers): jsodinjosdjsoinjsiojs@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Create two workspaces - A and B.
• Workspace A is the default workspace.

1. Go to staging.new.expensify.com
2. Create two reports in workspace chat A.
3. Create one report in workspace chat B.
4. Open FAB > Create expense > Manual.
5. Enter amount > Next.
6. On confirm page, click Report.
7. Select report from workspace B.
8. Click Report.
9. Click Create report.
   → To field shows workspace A avatar, but workspace B name,
10. Click To field.
    → Workspace A is selected.

Expected Result:

In Step 9, after changing report from another workspace and creating report, To field will show the default workspace avatar and name.

Actual Result:

In Step 9, after changing report from another workspace and creating report, To field shows workspace A avatar, but workspace B name.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7173021_1780693110723.20.mp4

View all open jobs on GitHub

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

[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/16c1c910941a25c1998b5c49aeb65e1079cdc491ee1129152795d72655d0d429

[melvin-bot]

Triggered auto assignment to @tylerkaraszewski (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.

[godzillaxbox19982014-lgtm]

Proposal

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

Expense-To field shows correct avatar but wrong name after creating new report on confirm page

What is the root cause of that problem?

I traced this to the path that handles workspace name, expense report, FAB:

• src/pages/iou/request/step/confirmation/DraftWorkspaceOpener.tsx:21 (DraftWorkspaceOpener): function DraftWorkspaceOpener({isCreatingTrackExpense, policyID, policyPendingAction, policyExpenseChatPolicyID, senderPolicyID, isOffline}: DraftWorkspaceOpenerProps) {
• src/pages/iou/request/step/confirmation/ExpenseDefaultsSetter.tsx:19 (ExpenseDefaultsSetter): function ExpenseDefaultsSetter({transactionIDs, policy, isPolicyExpenseChat, isMovingTransactionFromTrackExpense, isCreatingTrackExpense}: ExpenseDefaultsSetterProps) {
• src/pages/iou/request/step/confirmation/ExpenseDefaultsSetter.tsx:39 (matching code path): }, [transactionIDs, policy, isPolicyExpenseChat, isMovingTransactionFromTrackExpense, isCreatingTrackExpense]);
• The local evidence matches this recurring failure shape: optimistic transaction/report data is written to one Onyx key but the visible list reads another derived key. Here, src/pages/iou/request/step/confirmation/DraftWorkspaceOpener.tsx:21 and src/pages/iou/request/step/confirmation/ExpenseDefaultsSetter.tsx:19 do not agree on the same workspace name, expense report, FAB value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/pages/iou/request/step/confirmation/DraftWorkspaceOpener.tsx:21 to derive workspace name, expense report, FAB from the report/transaction source that owns this flow before the value is consumed.
• Carry the same normalized value through src/pages/iou/request/step/confirmation/ExpenseDefaultsSetter.tsx:19; that follows the safer family move to align optimistic/success/failure data with the selector consumed by the screen, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Reports, Expenses, IOU, Transactions surface and avoid changing payment actions, personal/deleted policies.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/unit/ReportUtils*.ts for the exact issue flow: Expense-To field shows correct avatar but wrong name after creating new report on confirm page.
2. Cover the counter-case near src/pages/iou/request/step/confirmation/DraftWorkspaceOpener.tsx:21 so valid existing workspace name, expense report, FAB behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep workspace name, expense report, FAB consistent at the first read/write boundary shown above.

[MelvinBot]

Issue Analysis

Root Cause: Regression introduced by Expensify/App#91554 (merged 2026-06-05, in 9.4.0-0 staging, not yet in production — matching "Reproducible in production?: No"). That PR changed how the "To" participant's name is derived, while the avatar is derived independently — so they can desync.

• Avatar comes from <ReportActionAvatars reportID={item.reportID} />, which fetches the report live from Onyx using the participant's reportID → shows the newly-created workspace A report. ✅ correct
• Name comes from item.text, set by getReportOption(...) → option.text = getPolicyName({report, policy}). After refactor getShareDestination and clean-up some util functions #91554 this trusts the caller-supplied policy instead of looking it up from report.policyID. The caller passes a policy derived through a multi-hop Onyx chain that lags behind transaction.participants, so on the render after "Create report" it still points at the previously-selected workspace B → shows WS-B name. ❌ wrong

The mismatch is exactly the avatar (live, WS-A) + name (stale-policy-derived, WS-B) the report describes.

The exact change in #91554 (verified from the PR diff):

-        option.text = getPolicyName({report});
+        option.text = getPolicyName({report, policy});

Previously getPolicyName({report}) resolved the name via report.policyID from allPolicies — always consistent with the avatar. Now it uses the passed policy, which can be stale.

Recommended Fix (surgical, deploy-blocker safe): Restore the report-derived name lookup at the affected getReportOption/sibling call sites in src/libs/OptionsListUtils/index.ts — revert the getPolicyName({report, policy}) calls back to getPolicyName({report}) at lines 1257, 1318, 1360, and 2326. This makes the name follow participant.reportID → report.policyID, identical to how the avatar resolves.

Alternatively, harden getPolicyName to only use the passed policy when policy.id === report.policyID, otherwise fall back to the report.policyID lookup — broader blast radius, so prefer the surgical revert for the blocker.

Given this is a DeployBlockerCash, the cleanest path may be to ping the author of #91554 (dukenv0307) for a quick fix-forward, or revert #91554 if a forward fix isn't fast.

Investigation details & evidence chain

Why the name source is stale (caller side): IOURequestStepConfirmation.tsx:260 calls getReportOption(participant, ..., policy, ...) where policy comes from usePolicyForTransaction → resolved through participants[0].reportID → participantReport → realPolicyID → policyReal. This cascade updates a render later than transaction.participants, so the row renders WS-A reportID (avatar) with WS-B policy (name).

Why the timing window exists: useReportSelectionActions.handleRegularReportSelection navigates back before the setTransactionReport Onyx merge (runAfterInteractions + microtask queue), so the user lands on the confirm page with old state while participants flip to WS-A and policy lags.

Why the new report is WS-A: in IOURequestStepReport.tsx:73-82, for a self-owned non-per-diem expense targetExpensePolicyID is undefined, so usePolicyForMovingExpenses falls back to the user's default/active workspace (A). "Create report" therefore always creates the new report in WS-A regardless of the previously-selected WS-B report.

Avatar vs name render points: UserListItemContent.tsx:99 (avatar, live Onyx) vs UserListItemContent.tsx:109 (item.text, precomputed).

Alternative explanations ruled out: PR #91279 (added reportDrafts subscription / reportDraft param to getReportOption, merged 2026-06-04) did NOT touch the getPolicyName call site, so it alone can't cause the name/avatar split. The split is uniquely produced by #91554's getPolicyName({report}) → getPolicyName({report, policy}) change.

Confidence: High — the regression PR, the exact diff line, the two desynced render sources, and the production-vs-staging behavior (bug only on staging) all corroborate.

---

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