[Due for payment 2026-08-10] Chat - Workspace chat name shows "Chat Report" after clear cache

[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-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: #96785
Email or phone of affected tester (no customers): ibellicotest+2766@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Left Hand Navigation (LHN)

Action Performed:

Prerequisite: Account has at least one workspace.

1. Open the staging.new.expensify.com website.
2. Navigate to Concierge chat.
3. Navigate to "Account" > "Troubleshoot"
4. Click on "Clear cache and restart" > "Reset and refresh"
5. Return to "Inbox"
6. Note that workspace chat shows "Chat Report" in LHN.

Expected Result:

Workspace chat name should remain the same after clearing cache and resetting app and all chats should load correctly.

Actual Result:

Workspace chat name changes to "Chat Report" after clearing cache and restarting app.
On Android app, Self DM also changes name to "Hidden".

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7219244_1785189865832.ONX8.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022082505623250386483
• Upwork Job ID: 2082505623250386483
• Last Price Increase: 2026-07-29

Issue Owner

Current Issue Owner: @shubham1206agra

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

[melvin-bot]

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

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

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #96785 - "Coalesce OnyxDerived recomputations via microtask scheduling" by @fabioh8010 (High confidence)
Related Issues: Originally landed as #95287, reverted in #95715 for a very similar class of stale-derived-value deploy blockers (#95696, #95698, #95700, #95721, #95753), then re-landed here as #96785.

Recommendation: REVERT

This PR rewrote the OnyxDerived delta/coalescing engine that feeds report‑name computation, and it is a re‑land of work that was already reverted once for the same stale‑derived‑data symptom class. Reverting restores the previous per‑callback sourceValues behavior and is safer than a forward fix on a deploy blocker affecting core LHN/report display and Concierge loading.

Assigned: @fabioh8010 (PR author), @mountiny and @shubham1206agra (approving reviewers) from the highest‑confidence causing PR.
Labels: No label change. DeployBlockerCash is correctly kept because an Expensify/App PR caused the issue and the App deploy must stay blocked. There is no DeployBlocker (Web) label on this issue to remove, and I am not removing any label added by an internal employee.

📋 Detailed Analysis

Evidence

• The symptoms are all "derived value computed against incomplete/stale Onyx data", which is exactly what this PR touches:
  • Workspace chat shows the raw fallback CONST.REPORT.DEFAULT_REPORT_NAME = 'Chat Report' (src/CONST/index.ts:1914) instead of the policy‑expense‑chat name, which computeReportName derives from policy + personalDetails (src/libs/ReportNameUtils.ts#L1060-L1062). If the report row is recomputed before its policy/personalDetails have repopulated, the derived reportName sticks at the fallback.
  • Self DM showing "Hidden" and Concierge stuck on the skeleton loader are the same "derived attributes were computed on a partial post‑clear snapshot and not re‑flushed" failure.
• Reproduces only after "Clear cache and restart" → "Reset and refresh" (staging), not on production. That flow (clearOnyxAndResetApp → clearOnyxAndSeedFullReconnect → Onyx.clear() → OpenApp re‑hydration, src/libs/actions/App.ts#L898-L937) is precisely the scenario that drives a burst of collection writes through the new coalescing engine — matching a timing‑sensitive bug that only manifests after a full clear/reload.
• This PR is a re‑land of Coalesce OnyxDerived recomputations via macrotask scheduling #95287, which was reverted in [CP Staging] Revert "Coalesce OnyxDerived recomputations via macrotask scheduling" #95715, for the same category of stale‑frame / stale‑read derived‑value deploy blockers. Re‑lands of previously‑reverted timing changes are the highest‑risk source of exactly this regression.

Verification

Files the bug depends on, and confirmation the PR modifies the mechanism behind them:

• Affected output: reportAttributes.reports[reportID].reportName, produced by src/libs/actions/OnyxDerived/configs/reportAttributes.ts → computeReportName in src/libs/ReportNameUtils.ts#L956.
• PR Coalesce OnyxDerived recomputations via microtask scheduling #96785 modifies exactly these files, per its file list: src/libs/actions/OnyxDerived/index.ts, src/libs/actions/OnyxDerived/configs/reportAttributes.ts, visibleReportActions.ts, sortedReportActions.ts, and adds src/libs/getCollectionDelta.ts.
• Confirmed the current staging code (9.4.45-1) contains this PR's changes verbatim: the microtask queueMicrotask(() => { flushRecompute(); }) coalescing engine at src/libs/actions/OnyxDerived/index.ts#L195-L211, and the triggeredKeys‑based incremental gating in reportAttributes.ts (L242-L266, L304-L311).
• No other PR in the 9.4.45 StagingDeployCash touches report‑name resolution or the OnyxDerived engine (e.g. [NoQA] Fix ESLint check failure: destructure isDraftPendingCompletion in MoneyRequestReportActionsList #97131 is an unrelated ESLint fix). This is the only candidate.

Root Cause

Before this PR, each Onyx dependency callback recomputed a derived value synchronously with sourceValues = {[sourceKey]: sourceValue}. This PR replaces that with coalesced, deferred recomputation: dependency changes in a synchronous burst are batched, and the delta (sourceValues) is reconstructed at flush time on a microtask by diffing each collection against a snapshot via the new getCollectionDelta (src/libs/getCollectionDelta.ts), keyed off triggeredKeys and per‑dependency baselines held in engine closure state (lastFlushedCollectionValues, hasFlushedOnce, pendingDependencyIndexes).

During "Reset and refresh", Onyx.clear() wipes the collections and OpenApp re‑hydrates them in a rapid multi‑write burst. In reportAttributes.ts the compute chooses between an incremental pass and a full scan based on currentValue?.reports and needsFullRecompute (L304-L311). With the new coalescing/baseline model, the report rows can be recomputed from a partial post‑clear snapshot — where the report exists but its policy/personalDetails/conciergeReportID inputs haven't been re‑diffed into sourceValues yet — and then are not re‑flushed once the remaining data lands, because the coalesced baseline already advanced. The result is derived reportName frozen at the 'Chat Report' fallback (and Self DM → "Hidden"), and Concierge's derived attributes never settling, leaving the infinite skeleton. This is the same stale‑read window that caused #95287 to be reverted as #95715; re‑landing it re‑introduced the regression under the clear‑cache path.