Expense - Contact name disappears in recipient list after reset app

[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-4
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #96785
Email or phone of affected tester (no customers): soidjnsodjoisjiodjios@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:

1. Go to staging.new.expensify.com
2. Open 1:1 DM with any user.
3. Send a message to the user.
4. Go to Account > Troubleshoot > Clear cache and restart > Reset and refresh.
5. Open FAB > Create expense > Manual.
6. Enter amount > Next.
7. Click To field.

Expected Result:

Contact name will not disappear in recipient list after reset app.

Actual Result:

Contact name disappears in recipient list after reset app.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

To be added by Applause Leads

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7219950

[melvin-bot]

@mountiny recently merged #96785, but they are OOO right now, so I'll auto-assign someone else.

[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/2c162b2cbeef6970d6874dfa9ba9d60315168a84c9bf3901785770f1d111a2d6

[melvin-bot]

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

[lanitochka17]

dupe #97250

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug (fix belongs in Expensify/App)
Causing PR: #96785 - "Re-land OnyxDerived recompute coalescing (microtask flush)" by @fabioh8010 (High confidence)
Related Issues: #97250 (duplicate, same repro, same suspected PR)

Recommendation: REVERT

PR #96785 re-lands the OnyxDerived recompute coalescing engine that was previously reverted (#95715) and has a track record of stale-derived-value regressions; the recipient list's contact name is read from the reportAttributes derived value, and the new coalescing/incremental-narrowing path can leave a report's derived reportName empty after a cache reset. A clean revert restores the last-known-good behavior with no dependent PRs on top of it.

Assigned: @fabioh8010 (PR author), @shubham1206agra (approving reviewer), @mountiny (approving reviewer / merger) from the highest-confidence causing PR
Labels: No changes. Kept DeployBlockerCash (App PR caused it → App deploy is correctly blocked). No DeployBlocker (Web) label was present, so nothing to remove. Not removing any label because there is a clear App PR cause.

📋 Detailed Analysis

Evidence

• The issue is reproducible on staging only, not production → a regression newly introduced in the current 9.4.45-4 release. PR Coalesce OnyxDerived recomputations via microtask scheduling #96785 is in the current StagingDeployCash checklist (merged 2026-07-24), and both this issue and its duplicate [Due for payment 2026-08-10] Expense - Contact name disappears in recipient list after reset app #97250 were auto-flagged against it.
• The repro specifically requires Account → Clear cache and restart → Reset and refresh before opening the expense To field. A cache reset wipes Onyx (including the reportAttributes derived value) and forces a full reload/recompute — precisely the code path Coalesce OnyxDerived recomputations via microtask scheduling #96785 rewrote.
• PR Coalesce OnyxDerived recomputations via microtask scheduling #96785 is a re-land of coalescing logic that was already reverted once ([CP Staging] Revert "Coalesce OnyxDerived recomputations via macrotask scheduling" #95715) and whose original landing (Coalesce OnyxDerived recomputations via macrotask scheduling #95287) produced five deploy blockers ([Due for payment 2026-07-17] Chat - Chat Report appears on user's name when start new chat #95696, [Due for payment 2026-07-17] Expense - Skeleton loader appears briefly after creating expense in the empty report #95698, [Due for payment 2026-07-17] Original expense briefly appears after splitting an expense #95700, [Due for payment 2026-07-17] iOS-Scan-Report preview is blank after dismissing the "Enjoying New Expensify" pop up #95721, Expense - Expense remains on the same report after being moved to new one in offline mode. #95753). This is the same class of "derived value briefly/persistently stale" symptom.

Verification

Affected render path for the recipient ("To") list:

• src/pages/iou/request/ParticipantSearchResults.tsx:168 reads the derived value: const reportAttributesDerived = useReportAttributes(); and passes it into the section/option formatter.
  

  App/src/pages/iou/request/ParticipantSearchResults.tsx

  Line 168 in de48e77

  // it does not apply bottom safe area padding itself, so the fixed footer must consume it. Otherwise the footer

• The row's display name is resolved by deprecatedGetReportName(report, reportAttributesDerivedValue) → getReportName in src/libs/ReportNameUtils.ts:1144, which returns reportAttributes?.[reportID]?.reportName ?? report.reportName ?? ''.
  

  App/src/libs/ReportNameUtils.ts

  Line 1144 in de48e77

  }

  
  For a 1:1 DM the name is derived from participant personal details, so report.reportName is empty — if the derived reportAttributes entry is missing/empty, the fallback yields '' and the contact name renders blank.

PR #96785 modifies exactly the code that populates that derived value:

• src/libs/actions/OnyxDerived/configs/reportAttributes.ts (display-name-change narrowing + triggeredKeys)
• src/libs/actions/OnyxDerived/index.ts (the coalescing microtask-flush engine + delta reconstruction)
• plus sortedReportActions.ts, visibleReportActions.ts, reportTransactionsAndViolations.ts, utils.ts, types.ts, getCollectionDelta.ts.

Confirmed: the PR touches the derived-value producer, and the affected feature consumes that exact derived value. Merge date (2026-07-24) precedes the report and the bug is absent on production (which predates this PR).

Root Cause

After a cache reset, Onyx reloads all keys in a synchronous broadcast burst and reportAttributes recomputes from an initially-empty currentValue. Two interacting changes in #96785 govern the DM's derived reportName:

1. Incremental vs. full recompute gate — src/libs/actions/OnyxDerived/configs/reportAttributes.ts:306:
   const useIncrementalUpdates = !!currentValue?.reports && Object.keys(currentValue.reports).length > 0 && !needsFullRecompute;
   

   App/src/libs/actions/OnyxDerived/configs/reportAttributes.ts

   Line 306 in de48e77

   const useIncrementalUpdates = !!currentValue?.reports && Object.keys(currentValue.reports).length > 0 && !needsFullRecompute;

2. Personal-details narrowing / short-circuit — reportAttributes.ts:247-248:
   const personalDetailsIsOnlyTrigger = triggeredKeys?.size === 1;
if (!displayNameChanges && personalDetailsIsOnlyTrigger) { return currentValue ...; }
   

   App/src/libs/actions/OnyxDerived/configs/reportAttributes.ts

   Lines 247 to 248 in de48e77

   	const personalDetailsIsOnlyTrigger = triggeredKeys?.size === 1;
   	if (!displayNameChanges && personalDetailsIsOnlyTrigger) {

The new engine (index.ts) coalesces the reload burst into a single microtask flush and reconstructs a delta (sourceValues) by diffing each dependency against a per-flush baseline. A 1:1 DM's display name depends on PERSONAL_DETAILS_LIST. When personal details land in a flush where reportAttributes already has a partially-populated currentValue (so useIncrementalUpdates is true), the recompute narrows to only the reports whose accountIDs appear in getDisplayNameChanges/reportReferencesAccountIDs. If the reload ordering means the DM's report was seeded into the derived value on an earlier flush (before its participants' personal details were reconstructed as a "change"), the DM never lands in personalDetailsChangedReportKeys, its derived reportName is never (re)computed against the loaded personal details, and it stays empty. The recipient row then falls back to the empty report.reportName and the contact name disappears.

This is a resurfacing of the same stale-derived-value hazard that caused the earlier revert (#95715): the coalescing + delta-reconstruction + incremental-narrowing scheme is order-sensitive on a full cold reload (cache reset), and the DM display-name path is one of the cases the narrowing drops.

Why REVERT over ROLL FORWARD

• The identical logic was reverted once already ([CP Staging] Revert "Coalesce OnyxDerived recomputations via macrotask scheduling" #95715); a targeted fix would need to re-prove correctness across the full reload ordering, which is exactly what has repeatedly regressed.
• No PRs depend on Coalesce OnyxDerived recomputations via microtask scheduling #96785 in the current checklist, so the revert is clean.
• A revert reintroduces only the send-latency perf regression the PR was optimizing — a performance trade-off, not a broken-UI/data hazard — which is the safer state to ship.