Merge - The common user contact chat is duplicated in recents after merging accounts

[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: v9.4.5-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-41434/folder/13176687/41236704/1478229665?sort=%2Bidentifier
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 15.4.1 Safari/Chrome
App Component: Other

Action Performed:

1. Go to https://staging.new.expensify.com
2. Log in to the account that will remain active (User A).
3. Log in to the account that will be merged (User B) and start a chat with User C.
4. Switch back to User A.
5. Start a chat with User C.
6. Merge User B into User A.
7. Click the + button > Start chat.

Expected Result:

The common user contact chat should appear only once in Recents after merging accounts.

Actual Result:

The common user contact chat is duplicated in recents after merging accounts

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7177492_1781143343825.Recording__2350.mp4

View all open jobs on GitHub

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

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

[melvin-bot]

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

[MelvinBot]

Issue Analysis

Root Cause: After merging User B into User A, the backend rewrites B's DM with C to use A's accountID — but it does not delete the now-duplicate report. So Onyx ends up holding two separate reports (different reportIDs) that both represent the same 1:1 DM between A and C. The "Start chat" recents list renders one row per reportID with no dedup by participant set, so C's chat shows twice.

This is almost certainly a backend merge regression (reproducible in staging, not production → the backend stopped emitting the duplicate-report cleanup in the merge payload). The App-side code has never deduped recents by participant — it just renders whatever reports exist in Onyx, so the data condition originates in the merge command, not in App.

Where the fix belongs: The real fix is outside the App repo (the account-merge backend that should consolidate/delete the duplicate DM report). This needs an internal engineer with backend access to identify the regressing deploy and restore the duplicate-report cleanup. As a deploy blocker, the fastest path is to identify and revert the backend PR that changed merge behavior around v9.4.5.

Investigation details (evidence)

App side has no participant-based dedup anywhere in the recents path:

• The options cache is keyed strictly by reportID — two reports with identical participants are two distinct entries: OptionListContextProvider.tsx:313
• createOptionList pushes every valid report into allReportOptions unconditionally — note the asymmetry: the personal-details map (reportMapForAccountIDs) is keyed by partner accountID so duplicates overwrite there, but allReportOptions.push() keeps both: OptionsListUtils/index.ts:1499-1538
• filterAndOrderOptions already has a defensive login-dedup — but it is applied only to personalDetails, not to recentReports: OptionsListUtils/index.ts:3276-3285. This is why the personal-detail row for C gets hidden but both recent-report rows survive.
• The Start chat screen renders recentReports straight from getValidOptions/filterAndOrderOptions with no further collapsing: NewChatPage/index.tsx:117-280

App side does nothing to reports on merge:

• mergeWithValidateCode only flips account.mergeWithValidateCode loading flags — it never rewrites participants or cleans up reports: MergeAccounts.ts:78-126. All report changes arrive via backend Onyx updates. There is no client-side handler anywhere that swaps B's accountID for A's or removes orphaned duplicate reports.

Why this confirms a backend root cause: Production uses the same App rendering code (no recents dedup) yet does not show the duplicate. The only thing that differs is the data — production's merge payload deletes the duplicate report, staging's apparently doesn't.

Possible client-side mitigation (masks, not fixes): A defensive dedup could be added for 1:1 reports sharing the same partner accountID in filterAndOrderOptions (mirroring the existing personalDetails login-dedup at index.ts:3276). This would hide the symptom but leave two stale DM reports in Onyx — the backend cleanup is the correct fix.

Confirming via logs (recommended): Check the merge command's onyxData payload on staging vs production for a report_<old-id> = null (delete) entry. The issue has no usable accountIDs (Applause tester, email n/a), so this needs a fresh staging repro to capture identifiers.

---

Next Steps: This is a backend/internal regression — please escalate to an internal engineer to identify and revert the merge-related backend deploy. Reply with @MelvinBot <feedback> to refine this analysis.

[youssef-lr]

@MelvinBot check if there is an offending Web-E PR

[MelvinBot]

I can't directly identify the Web-E PR — MelvinBot doesn't have read access to the private Expensify/Web-Expensify repo (clone returns 403, and PR/API lookups return 404), so I can't search its history.

Here's the targeting info to find it manually, based on the analysis above:

What to look for

• A PR that changed the account-merge backend path — specifically the step that, after re-pointing User B's DM with C onto User A's accountID, is supposed to delete the now-duplicate report (report_<oldID> = null in the merge command's onyxData). The regression looks like that delete/consolidation step being dropped, leaving two reportIDs for the same A↔C 1:1.

Why "staging only" points at a backend deploy

• staging.new.expensify.com runs against the staging backend. A Web-E (or Auth) merge PR that's deployed to staging but not yet production would reproduce exactly this way — staging shows the duplicate, production doesn't. The App rendering code is identical in both environments and has never deduped recents by participant, so the differing factor is the merge payload, not App.

How to find it (with Web-E access)

• Diff Web-E staging vs production for PRs touching the merge command (the handler that merges an account and rewrites/cleans up reports) and look for one merged around 2026-06-10/11.
• Confirm by capturing the merge command's onyxData on a fresh staging repro and checking whether the duplicate report_<id> delete is present (production) or missing (staging).

If it isn't a Web-E PR, the same logic applies to Auth (the merge command lives in the backend either way). I'd need an internal engineer with backend repo access to pull the exact PR.