[Due for payment 2026-07-17] Chat - Chat Report appears on user's name when start new chat

[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.32-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-54985/folder/13176683/41236561/1554721318?sort=%2Bstatus_id
Email or phone of affected tester (no customers): gocemate+buzz1807@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: windows 10/chrome
App Component: Other

Action Performed:

1. Go to FAB> Start chat> Enter user email address
2. Select user to create new chat

Expected Result:

Chat Report should not be displayed at user's name place

Actual Result:

Chat Report is displayed at user's name place

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7203738_1783597530687.Recording__1073.mp4

View all open jobs on GitHub

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

[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/5b3a262db2fd27b1675bdadde190b7fde4be2eb6b4127c83e5bb1c5889a99cbc

[melvin-bot]

Triggered auto assignment to @cristipaval (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]

📣 @vapegobugu! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[MelvinBot]

Issue Analysis

Root Cause: When a new 1:1 chat is created optimistically, the header/LHN renders before the derived reportAttributes value (which holds the real, participant-derived report name) has been computed. In that window, getReportName falls back to report.reportName, which for a fresh optimistic chat is set to CONST.REPORT.DEFAULT_REPORT_NAME = 'Chat Report' (CONST/index.ts:1880). So the literal string "Chat Report" is shown instead of the user's name.

This is a regression from #95287 ("Coalesce OnyxDerived recomputations via macrotask scheduling", merged 2026-07-08, in this deploy — checklist #95677). That PR changed recomputeDerivedValue to defer the reportAttributes recompute onto a macrotask instead of running it synchronously (OnyxDerived/index.ts:195-201). Before #95287 the derived name was already populated by the time the new chat rendered; now the render wins the race and shows the fallback. This matches the staging-only / production-safe split.

Recommended Fix: Eliminate the empty-derived-value window on optimistic report creation while keeping #95287's coalescing win for bulk updates — flush the reportAttributes recompute synchronously when a brand-new report key first appears in the REPORT delta (i.e. don't defer the first population of a report). If the deploy needs to be unblocked immediately, CP-revert #95287 (item 42 in checklist #95677).

Investigation details

Code path (input → bug → symptom):

1. FAB > Start chat > select user → navigateToAndOpenReport (Report/index.ts:2289) builds an optimistic report (buildOptimisticChatReport, participants set, reportName defaulted to 'Chat Report' at ReportUtils.ts:7862), calls openReport (SETs the report with reportName: DEFAULT_REPORT_NAME at Report/index.ts:1735-1738), then synchronously navigates.
2. Header (HeaderView.tsx:164) and avatar/LHN (AvatarWithDisplayName.tsx:211) render immediately, calling getReportName(report, reportAttributes).
3. Coalesce OnyxDerived recomputations via macrotask scheduling #95287 deferred the reportAttributes recompute to a macrotask, so reportAttributes[newReportID] is not yet populated.
4. getReportName returns report.reportName = 'Chat Report'.

The computed path is otherwise correct: for a plain 1:1 CHAT, computeReportName → buildReportNameFromParticipantNames resolves the participant display name — it just hasn't run yet at first paint. #95287's own test diff (tests/ui/components/HeaderViewTest.tsx) even documents that "the title can settle a tick after," confirming the timing shift.

Note on transient vs. persistent: the reporter's video suggests the wrong name persists rather than flashing for one tick. If so, there may be a secondary miss in the delta / personalDetailsIsOnlyTrigger short-circuit in reportAttributes.ts that leaves the new report's derived name stale on a later settle — worth confirming whether the fix needs to also address that, or is purely the timing window.

App repo checkout here is a shallow clone (1 commit), so introducing-PR attribution was done via gh pr/deploy-checklist history rather than local git blame.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.