[Due for payment 2026-08-10] Expense - Contact name disappears in recipient list after reset app

[lanitochka17]

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

Bug7219950_1785250493134.15.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @shubham1206agra

[melvin-bot]

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

[melvin-bot]

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

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

🔍 Investigation Summary

Classification: Frontend bug (fix is in Expensify/App)
Causing PR: #96785 - "Coalesce OnyxDerived recomputations via microtask scheduling" by @fabioh8010 (High confidence)
Related Issues: #97251 (duplicate — same repro, version 9.4.45-4, same suspected PR)

Recommendation: REVERT

PR #96785 re-lands the OnyxDerived recompute coalescing engine that was already reverted twice for causing a cluster of stale-derived-data deploy blockers, and this regression is the same failure class: after a cache reset, the DM's reportAttributes.isEmpty stays stale/true, so the 1:1 chat is filtered out of the recipient list. Reverting restores the per-dependency recompute that does not have this staleness window.

Assigned: @fabioh8010 (PR author), @shubham1206agra and @mountiny (approving reviewers) from PR #96785
Labels: No change. DeployBlockerCash kept (App deploy is correctly blocked for a frontend regression). DeployBlocker (Web) was not present, so nothing to remove.

📋 Detailed Analysis

Evidence

• The issue and its duplicate Expense - Contact name disappears in recipient list after reset app #97251 both explicitly link PR Coalesce OnyxDerived recomputations via microtask scheduling #96785 in the "caught during regression" field, and Melvin flagged @mountiny recently merged #96785. Coalesce OnyxDerived recomputations via microtask scheduling #96785 merged 2026-07-24, landing in the 9.4.45 staging release where the bug first appears — reproducible on staging only, not production, consistent with a PR still on staging.
• PR Coalesce OnyxDerived recomputations via microtask scheduling #96785 is a re-land of the OnyxDerived coalescing work first introduced in Coalesce OnyxDerived recomputations via macrotask scheduling #95287, which was reverted for causing deploy blockers, re-landed, and reverted again. Its own description lists five prior 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) all rooted in stale/dropped derived-value updates. The commit history on src/libs/actions/OnyxDerived/index.ts confirms this revert/re-land churn ("Revert OnyxDerived macrotask coalescing", "Revert Revert…", "Use queueMicrotask instead of macrotask").
• The repro flow (send a DM message → Clear cache and restart → open Create expense → "To" field) is exactly the kind of full-collection re-broadcast burst that the new coalescing/delta-reconstruction path handles, and the symptom (a chat that HAS a visible message being treated as empty and dropped from the option list) is a textbook stale-derived-value symptom.

Verification

The recipient list is built by OptionsListUtils, which filters reports via shouldReportBeInOptionList → reasonForReportToBeInOptionList in src/libs/ReportUtils.ts. A non-empty DM is dropped only when it is judged empty:

• src/libs/ReportUtils.ts:9942 computes const isEmptyChat = isEmptyReport(report, isReportArchived);
• src/libs/ReportUtils.ts:9996-10008 returns null (excludes the chat) when excludeEmptyChats && isEmptyChat && isChatReport(report) && … && canHideReport — this is what makes the contact name disappear from the "To" list.
• isEmptyReport reads the derived value directly:
  src/libs/ReportUtils.ts:9187-9189 → const attributes = reportAttributesDerivedValue?.[report.reportID]; if (attributes) { return attributes.isEmpty; }

So the option list's empty-chat filter is driven entirely by the REPORT_ATTRIBUTES derived value, and reportAttributes is one of the configs rewritten by PR #96785 (files changed include configs/reportAttributes.ts, configs/visibleReportActions.ts, configs/sortedReportActions.ts, and the coalescing engine OnyxDerived/index.ts + new getCollectionDelta.ts). Confirmed PR #96785 modifies these exact files.

Root Cause

PR #96785 stops using Onyx's own sourceValue and instead reconstructs the changed-member delta at flush time by diffing the current collection snapshot against a snapshot captured on the previous flush:

• src/libs/actions/OnyxDerived/index.ts:80-81 — lastFlushedCollectionValues baseline + hasFlushedOnce flag are held in the per-key init() closure, created once at app startup.
• src/libs/actions/OnyxDerived/index.ts:132-137 — once hasFlushedOnce is true, the delta is getCollectionDelta(current, lastFlushedCollectionValues[index]), and getCollectionDelta (src/libs/getCollectionDelta.ts:12-42) only emits members whose reference differs from the baseline.

"Clear cache and restart → Reset and refresh" clears Onyx and re-broadcasts every collection member through the existing connection callbacks (the init() closures are not re-created, so hasFlushedOnce is already true and the pre-reset baselines are still in lastFlushedCollectionValues). During that re-broadcast burst, reportAttributes then relies on the coalesced delta to decide what to recompute:

• src/libs/actions/OnyxDerived/configs/reportAttributes.ts:306 — useIncrementalUpdates is true whenever currentValue.reports is non-empty (which it is, restored from disk/prior compute).
• src/libs/actions/OnyxDerived/configs/reportAttributes.ts:361-441 — in the incremental path, only reports appearing in the reconstructed sourceValues delta (report / report-action / metadata updates) are recomputed; if the delta for the DM's REPORT_ACTIONS member is lost or split across bursts (a known hazard the PR itself calls out for sortedReportActions/reportTransactionsAndViolations where coalescing "would drop the second trigger"), the DM's isEmpty is never recomputed and remains true from before the message/reset settled.

With isEmpty stuck at true, reasonForReportToBeInOptionList filters the DM out at ReportUtils.ts:9996-10008, so the just-messaged contact vanishes from the manual-expense "To" recipient list — matching the report exactly, and matching the stale-derived-value class of the five blockers #96785 was meant to fix.

Because the fix requires changing Expensify/App code (revert or repair the coalescing engine), this is a Frontend bug and DeployBlockerCash should remain.

Recommendation detail: REVERT vs ROLL FORWARD

REVERT is recommended over a targeted fix because (a) this exact coalescing mechanism has already produced multiple deploy blockers across two prior land/revert cycles, indicating the delta-reconstruction approach is fragile under full re-broadcast bursts; (b) a targeted fix would need to prove correctness of delta reconstruction after cache reset across every derived config, which is higher risk under deploy-blocker time pressure than restoring the known-good per-dependency recompute. If the perf win must be preserved, roll forward only with a fix that forces a full (non-incremental) recompute after a storage clear/re-broadcast.