[$250] Workspace - Primary login displayed as hidden after merged with other account

[izarutskaya]

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.3.80-4
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: EDGE https://github.com/Expensify/Expensify/issues/362457
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856

Action Performed:

Precondition: all accounts should be expensifail

1. Log in as Account A
2. Create a Workspace
3. Invite other existing accounts B and C to the workspace
4. Send some messages in the #Announce room and in the workspace chat for the 2 users you have access to
5. Remove the account C from the workspace
6. Navigate to OldDot and Log in with account B
7. Merge the account B with the account C (that was just removed from the workspace)
8. Navigate back to the new expensifail app and Log In with account B
9. Tap on Search Icon and write the created workspace name in step 2 e.g. "Workspace 28"
10. Tap on the archived workspace
11. Repeat step 9-10

Expected Result:

Primary login is displayed as initial account in header, search page and conversation

Actual Result:

Primary login displayed as hidden in header, search page and conversation

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7136576_1776946251140.merged_account.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022058871801502762926
• Upwork Job ID: 2058871801502762926
• Last Price Increase: 2026-05-25

[MelvinBot]

Proposal

What is the root cause of that problem?

After Account B merges with Account C (which was previously removed from the workspace), the archived workspace report still references Account C's old accountID in its participant list. However, the personalDetailsList Onyx store no longer has an entry for that old accountID (or the entry has been cleared by the backend during the merge).

The display name resolution chain then follows this path:

1. getDisplayNameForParticipant looks up personalDetails[oldAccountID], gets null, and creates an optimistic stub {isOptimisticPersonalDetail: true} with no login — returning empty string
2. buildReportNameFromParticipantNames filters out participants with empty names
3. The report name resolves to empty string
4. DisplayNames falls back: '' || translate('common.hidden') → shows "Hidden"

The same mechanism causes "Hidden" in search results via getDisplayNameOrDefault, which returns hiddenTranslation when personalDetails has no displayName and no login.

The core problem is that the merge operation (handled entirely server-side — MergeAccounts.ts has no client-side Onyx updates for personalDetails) either removes Account C's personalDetails entry without updating the report's participant list to use Account B's accountID, or fails to push the updated personalDetails for the merged account to the client.

What changes do you think we should make in order to solve the problem?

This appears to be a backend/internal issue. The server-side merge logic needs to ensure that when accounts are merged, either:

1. All report participant references to the old accountID are updated to the new accountID, or
2. The personalDetailsList entry for the old accountID is preserved (pointing to the surviving account's details) so the client can still resolve a display name

A separate internal investigation is needed to trace the exact OnyxUpdate pushes sent by the backend during the merge operation.

On the App side, a defensive improvement could be made in getDisplayNameForParticipant: when personalDetails is missing for a participant and the report has an ACCOUNT_MERGED archive reason, look up the newAccountID from the archived action's originalMessage and use that account's personalDetails instead of showing "Hidden".

What alternative solutions did you explore? (Optional)

• Client-side merge handling: Adding optimistic Onyx updates in MergeAccounts.ts to remap participant accountIDs. Rejected because the App doesn't have enough information client-side to know which reports need updating — the server is the source of truth for all participant/member data.
• Fallback to report reportName field: The archived report may already have a cached reportName from before the merge, but this field can also be empty or stale after the merge Onyx push.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[Abdukhamid000]

Proposal

What is the root cause of that problem?

After the OldDot merge, the personal-details entry for the surviving primary account (B) comes back with displayName set to just the merge marker (MERGED_<id>@) and no login — the original email/displayName fields were lost in the merge. getDisplayNameOrDefault strips the marker prefix, ends up with an empty displayName and an empty login, and falls through to the "hidden" fallback for every render that asks for B's display.

The relevant logic in [PersonalDetailsUtils.ts:55-101](https://github.com/Expensify/App/blob/main/src/libs/PersonalDetailsUtils.ts#L55-L101):

let displayName = passedPersonalDetails?.displayName ?? '';
let login = passedPersonalDetails?.login ?? '';

if (regexMergedAccount.test(displayName)) {
    displayName = displayName.replaceAll(CONST.REGEX.MERGED_ACCOUNT_PREFIX, '');
}
...
if (displayName) { return displayName; }
if (defaultValue) { return defaultValue; }
if (login) { return login; }
return shouldFallbackToHidden ? hiddenTranslation : '';

Walking the repro:

1. B and C are both in the workspace and have valid personalDetails. C is removed.
2. B and C are merged in OldDot (B is the primary). The merge collapses C's accountID into B's row server-side and rewrites B's personalDetails entry: displayName = "MERGED_<C_accountID>@", login = "" (the BE marks the merge but doesn't repopulate B's display info on this code path).
3. B logs back in. The Onyx push hydrates personalDetails[B_accountID] with the marker-only shape.
4. The header / search row / conversation read personalDetails[B_accountID] and call getDisplayNameOrDefault. The regex strips MERGED_<id>@ → displayName = "". No defaultValue. login = "". shouldFallbackToHidden is true by default → returns the localized "hidden" string.

Two contributing smells in the same function:

• regexMergedAccount is a module-singleton built from a global-flag pattern. CONST.REGEX.MERGED_ACCOUNT_PREFIX is /^(MERGED_\d+@)/g, and new RegExp(pattern) with .test() calls on a g-flagged regex carries lastIndex across calls. The first .test() on a given displayName returns true, advances lastIndex past MERGED_<id>@, and the next .test() (next render, same string) starts searching from there — ^ no longer matches → returns false → replaceAll is skipped → the raw MERGED_<id>@… shows through in the UI. So depending on render parity, B's name flickers between "hidden" and MERGED_<id>@. Both are wrong.
• Empty-after-strip is treated the same as unknown. Once we know a displayName was a merge marker, we know whose primary login it is — but the function discards that signal and falls through to the generic "hidden" path.

So the "hidden" label has two avenues to get rendered for the currently logged-in user, and there's no fallback to the session login.

What changes do you think we should make in order to solve the problem?

Three small changes in getDisplayNameOrDefault, all in one diff:

-const regexMergedAccount = new RegExp(CONST.REGEX.MERGED_ACCOUNT_PREFIX);
+// Use a non-stateful, non-global pattern for the test. We still strip via the global
+// CONST.REGEX.MERGED_ACCOUNT_PREFIX inside replaceAll (replaceAll requires a g flag).
+const MERGED_ACCOUNT_TEST = /^MERGED_\d+@/;
@@
 function getDisplayNameOrDefault(
     passedPersonalDetails?: Partial<PersonalDetails> | null,
     defaultValue = '',
     shouldFallbackToHidden = true,
     shouldAddCurrentUserPostfix = false,
     youAfterTranslation = youTranslation,
 ): string {
     let displayName = passedPersonalDetails?.displayName ?? '';
     let login = passedPersonalDetails?.login ?? '';
+    const hadMergedPrefix = MERGED_ACCOUNT_TEST.test(displayName);

-    if (regexMergedAccount.test(displayName)) {
+    if (hadMergedPrefix) {
         displayName = displayName.replaceAll(CONST.REGEX.MERGED_ACCOUNT_PREFIX, '');
     }
@@
     if (displayName) { return displayName; }
     if (defaultValue) { return defaultValue; }
     if (login) { return login; }
+
+    // If the original displayName was just a merge marker with nothing after it AND we know
+    // who this account is (current user), fall back to the session login so the primary user
+    // doesn't render as "hidden" after merging another account into theirs.
+    if (hadMergedPrefix && passedPersonalDetails?.accountID && currentUserAccountID && passedPersonalDetails.accountID === currentUserAccountID && currentUserEmail) {
+        return currentUserEmail;
+    }
+
     return shouldFallbackToHidden ? hiddenTranslation : '';
 }

currentUserAccountID and currentUserEmail come from the same Onyx.connect pattern that already populates hiddenTranslation/youTranslation at module level (subscribe to ONYXKEYS.SESSION once, mirror into module vars). The function stays sync.

Why each piece matters:

• Replacing regexMergedAccount with a non-global MERGED_ACCOUNT_TEST removes the lastIndex flicker — every render now strips consistently. This alone gets rid of the "name flips to MERGED_xxx@…" half of the symptom.
• The session-login fallback catches the case where the BE's merge response leaves the surviving user with an empty post-strip displayName. The data we need (the session's primary login) is already in Onyx — we just don't reach for it today.
• Confining the fallback to accountID === currentUserAccountID keeps the change scoped: random merged-then-orphaned accounts other users see should still render as "hidden" (we don't have their primary login to substitute). Only the current user gets the session-backed display, which matches the bug's title — "Primary login displayed as hidden."

I'd add two unit tests in PersonalDetailsUtilsTest:

• displayName = "MERGED_12345@", login = "", accountID === current → returns session email.
• Same input with a different accountID → still returns hiddenTranslation (no over-reach).

A follow-up worth filing separately: when the BE merges B with C and the surviving account's displayName comes back as a bare marker, the source of truth is wrong — the client patch above prevents user-visible breakage, but the backend should ideally repopulate displayName/login after a merge so this fallback is rarely needed. That's a Server-side ticket, not in scope here.

What alternative solutions did you explore?

• Always return passedPersonalDetails.login even when empty. Doesn't help — the BE returned an empty login too. We need data from outside the personalDetails entry, which is what the session lookup provides.
• Block rendering on a "merged but not yet refreshed" loading state. Heavier — needs a new Onyx key and a render gate on every consumer of getDisplayNameOrDefault. The synchronous fallback is the cheaper fix.
• Strip the regex change entirely and rely on the BE to never send the merge prefix to the client. That's the cleanest long-term answer, but until the server stops sending it the client still has to handle the stateful-regex bug and the empty-after-strip case.

[MobileMage]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After merging two accounts in OldDot (B + C) and then signing into NewDot as the primary login B, opening the archived workspace chat shows the merged participant as "Hidden" in the header, search results, and conversation instead of the primary login.

What is the root cause of that problem?

After a merge, the backend re-labels the absorbed account's personal details by prefixing both displayName and login with MERGED_<primaryAccountID>@. getDisplayNameOrDefault is supposed to strip that prefix, but it has two problems that combine to make the value collapse to the common.hidden fallback.

First, the regex used for the check is a module-level global regex (MERGED_ACCOUNT_PREFIX: /^(MERGED_\d+@)/g). Because regexMergedAccount.test(...) is called on a stateful /g regex, lastIndex advances after each successful match. The next call against a different string (or even the same string on the next render) starts matching from that non-zero lastIndex, and since the regex is anchored with ^, test() returns false — so the replaceAll branch is skipped and the prefix is never stripped.

App/src/libs/PersonalDetailsUtils.ts

Lines 55 to 72 in cf13013

	const regexMergedAccount = new RegExp(CONST.REGEX.MERGED_ACCOUNT_PREFIX);
	function getDisplayNameOrDefault(
	passedPersonalDetails?: Partial<PersonalDetails> | null,
	defaultValue = '',
	shouldFallbackToHidden = true,
	shouldAddCurrentUserPostfix = false,
	youAfterTranslation = youTranslation,
	): string {
	let displayName = passedPersonalDetails?.displayName ?? '';
	let login = passedPersonalDetails?.login ?? '';
	// If the displayName starts with the merged account prefix, remove it.
	if (regexMergedAccount.test(displayName)) {
	// Remove the merged account prefix from the displayName.
	displayName = displayName.replaceAll(CONST.REGEX.MERGED_ACCOUNT_PREFIX, '');
	}

Second, even on the runs where displayName is stripped, login is never sanitized. So when the stripped displayName is empty (e.g. backend stored only MERGED_<id>@ with no domain, or displayName equaled login) the fallback chain hits the still-prefixed login, fails the visible-string check downstream in getDisplayNameForParticipant, and ultimately resolves to the hidden translation.

What changes do you think we should make in order to solve the problem?

The fix has two parts, both inside src/libs/PersonalDetailsUtils.ts. Replace the regex.test(displayName) guard with a plain String.prototype.startsWith check (or call displayName.replace(...) unconditionally) so we no longer depend on the shared stateful regex. Then apply the same prefix-strip to login right after displayName, so the fallback chain in getDisplayNameOrDefault (and any caller that reads personalDetails.login after this normalization) never returns the raw MERGED_<id>@… string and never collapses to "Hidden" for a merged account.

App/src/libs/PersonalDetailsUtils.ts

Lines 66 to 81 in cf13013

	let login = passedPersonalDetails?.login ?? '';
	// If the displayName starts with the merged account prefix, remove it.
	if (regexMergedAccount.test(displayName)) {
	// Remove the merged account prefix from the displayName.
	displayName = displayName.replaceAll(CONST.REGEX.MERGED_ACCOUNT_PREFIX, '');
	}
	// If the displayName is not set by the user, the backend sets the displayName same as the login so
	// we need to remove the sms domain from the displayName if it is an sms login.
	if (Str.isSMSLogin(login)) {
	if (displayName === login) {
	displayName = Str.removeSMSDomain(displayName);
	}
	login = Str.removeSMSDomain(login);
	}

As a follow-up, the MERGED_ACCOUNT_PREFIX constant should drop the /g flag since it is only ever used inside .replaceAll/.replace calls that already take a global pattern internally — leaving /g on a shared regex is the footgun that keeps biting test() callers elsewhere (e.g. useReportActionAvatars).

What alternative solutions did you explore? (Optional)

N/A

[mukhrr]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-25 11:38:04 UTC.

Proposal

What is the root cause of that problem?

Three distinct defects compound on the repro path. After OldDot merges C into B and B reopens the archived workspace in NewDot, the participant lookup that drives the header subtitle, the search row, and the conversation participant labels resolves to common.hidden even though the data needed to display the surviving account is already on the client.

1) The header and search resolve a stale accountID and never follow the merge. The archived report's participant list still points at C's pre‑merge accountID. The client already has the oldAccountID → newAccountID mapping for this report — it lives in the report's last ACCOUNT_MERGED closed action's originalMessage (src/types/onyx/OriginalMessage.ts#L281-L290). The archive footer reads exactly that mapping and uses newAccountID for the surviving display name (src/components/ArchivedReportFooter.tsx#L36-L40), which is exactly why the footer text is right while the header and search row are wrong — the latter two route through getDisplayNameForParticipant (src/libs/ReportUtils.ts#L3330-L3389) without ever consulting the merge mapping the footer relies on.

2) The shared merge‑prefix test regex is stateful. MERGED_ACCOUNT_PREFIX is defined with the /g flag (src/CONST/index.ts#L4765) and PersonalDetailsUtils.ts builds a module singleton from it (#L55) that is then called via .test() at #L69. With /g, RegExp#test advances lastIndex after a successful match. The next .test() on the same shared regex — same string, same render, or a different consumer in a hot loop — starts searching from the non‑zero lastIndex; the ^ anchor then fails and test() returns false, so the replaceAll branch is skipped and the MERGED_<id>@… prefix leaks through unstripped. The display flickers between "Hidden" and the raw MERGED_<id>@… depending on render parity.

3) The prefix strip is asymmetric. Even when the regex bug doesn't bite, the strip is only applied to displayName. login is read as‑is at #L99-L102. The avatar layer already strips the same prefix from the login || … chain (src/components/ReportActionAvatars/useReportActionAvatars.ts#L368), so the avatar tooltip resolves correctly while the text label collapses. That asymmetry is direct evidence the prefix can appear in login.

Net effect on the repro: in the cases where (2) and (3) don't fully break the string, (1) is still the dominant bug — the merge‑away account's personalDetails row is either an optimistic stub with no login (ReportUtils.ts#L3315-L3317 and #L3351-L3354) or a scrubbed merge stub, and the function falls through to hiddenTranslation.

This is also why the popular "fall back to the current user's session login" patch is incomplete: it only repairs the view for the user who did the merge. When account A (the workspace creator) or any other workspace member opens the same archived report, the merged participant still has no session login to substitute, so they keep seeing "Hidden". Resolving to newAccountID fixes the display for every viewer because they all hold the surviving account's personalDetails.

What changes do you think we should make in order to solve the problem?

Three minimal, additive changes. Each one fixes a distinct defect; the accountID remap is the architectural fix that makes the bug go away for every viewer, the regex/strip changes are the cleanup that prevents the symptom from leaking into any other consumer of getDisplayNameOrDefault.

Change 1 — Remap merged accountIDs at the participant‑resolution layer (the architectural fix).

Add a small helper in src/libs/ReportUtils.ts next to getDisplayNameForParticipant:

+// Returns the surviving `accountID` if `accountID` was merged away in this report,
+// by reading the same `ACCOUNT_MERGED` closed action that `ArchivedReportFooter`
+// already consumes. Keeps the lookup path consistent between the footer text
+// and the header/search labels.
+function getSurvivingAccountID(reportID: string | undefined, accountID: number | undefined): number | undefined {
+    if (!reportID || !accountID) {
+        return accountID;
+    }
+    const closed = getLastClosedReportAction(getReportActions(reportID));
+    const original = isClosedAction(closed) ? getOriginalMessage(closed) : null;
+    if (original?.reason === CONST.REPORT.ARCHIVE_REASON.ACCOUNT_MERGED && original.oldAccountID === accountID && original.newAccountID) {
+        return original.newAccountID;
+    }
+    return accountID;
+}

Then thread an optional reportID into getDisplayNameForParticipant and remap at entry:

 function getDisplayNameForParticipant({
     accountID,
+    reportID,
     shouldUseShortForm = false,
     shouldFallbackToHidden = true,
     shouldAddCurrentUserPostfix = false,
     personalDetailsData = allPersonalDetails,
     shouldRemoveDomain = false,
     formatPhoneNumber,
 }: {
     accountID?: number;
+    reportID?: string;
     ...
 }): string {
-    if (!accountID) {
+    const resolvedAccountID = getSurvivingAccountID(reportID, accountID);
+    if (!resolvedAccountID) {
         return '';
     }
-    const personalDetails = getPersonalDetailsOrDefault(personalDetailsData?.[accountID]);
+    const personalDetails = getPersonalDetailsOrDefault(personalDetailsData?.[resolvedAccountID]);

Update the two callers that have reportID in scope:

• src/libs/ReportNameUtils.ts at L216, L227, L279, L1013 — pass the report's reportID when building the report name.
• src/libs/OptionsListUtils/index.ts at L1179, L1183 — pass report?.reportID when building search options.

Callers without report context (e.g. SelfDM owner display at ReportNameUtils.ts:299/403) simply omit reportID; the function falls back to the existing behavior. ArchivedReportFooter is unchanged.

Change 2 — Stop sharing a stateful /g regex for .test().

In src/libs/PersonalDetailsUtils.ts:

-const regexMergedAccount = new RegExp(CONST.REGEX.MERGED_ACCOUNT_PREFIX);
+// Non-stateful pattern for `.test()`. The `/g` flag on the shared
+// `CONST.REGEX.MERGED_ACCOUNT_PREFIX` (used inside `replaceAll`) makes `.test()`
+// advance `lastIndex` between calls — which causes the next render to skip the
+// strip and render `MERGED_<id>@…` directly.
+const MERGED_ACCOUNT_TEST = /^MERGED_\d+@/;

The global pattern stays exactly as-is for replaceAll (which does not share lastIndex with the local test regex). Any other consumer that wants to test should also use a non-global pattern; auditing the rest of the codebase, useReportActionAvatars is fine because it goes straight to replaceAll.

Change 3 — Symmetric prefix strip on login.

-    if (regexMergedAccount.test(displayName)) {
+    if (MERGED_ACCOUNT_TEST.test(displayName)) {
         displayName = displayName.replaceAll(CONST.REGEX.MERGED_ACCOUNT_PREFIX, '');
     }
+    if (MERGED_ACCOUNT_TEST.test(login)) {
+        login = login.replaceAll(CONST.REGEX.MERGED_ACCOUNT_PREFIX, '');
+    }

This matches what the avatar layer already does at useReportActionAvatars.ts:368 and removes the last path by which a MERGED_<id>@… string can leak into the UI.

Supporting bits (no separate diffs needed):

• Add a unit test that constructs an archived report with an ACCOUNT_MERGED closed action mapping oldAccountID → newAccountID, plus an optimistic-stub personalDetails[oldAccountID], and asserts the header / search row render newAccountID's login. Assert this holds when the viewer is not the user who did the merge — the case the session-login fallback proposals miss.
• Add a /g-stateful regression test: call getDisplayNameOrDefault twice in a row with displayName: "MERGED_123@foo@bar.com" and assert both calls return "foo@bar.com". This will fail today on the second call because lastIndex has moved.
• Scope: no backend change; no merge optimistic-data change; shouldFallbackToHidden = false contracts untouched; genuinely unknown participants (no ACCOUNT_MERGED mapping) still correctly render "Hidden".

A follow-up worth filing separately on Expensify/Expensify: after a merge, the archived report's participants array should be rewritten server-side to point at the surviving accountID. The client read-time remap above is correct today; the server-side fix would let us delete the helper later.

What alternative solutions did you explore?

• Session-login fallback in getDisplayNameOrDefault (proposed in multiple existing comments on this issue). Rejected: it only repairs the view for the user who performed the merge. Any other workspace member viewing the same archived report still sees "Hidden" because they have no session login for the merged-away account. The accountID remap covers all viewers.
• firstName/lastName fallback before hiddenTranslation. Fragile — the merge stub can blank those fields too, and even when it doesn't, it shows the wrong identity (the merged-away C, not the surviving B). The remap is more correct because it resolves to the actual surviving account.
• Eagerly rewrite personalDetailsList / report participants on the client post-merge. Bigger change, touches many files, and the canonical mapping lives on the server. Better as a separate server-side ticket; the read-time remap is one helper and reversible.
• Move the strip into the Onyx write path so personalDetails rows never contain the prefix in memory. Cleaner long-term, but it adds a global transform layer for a convention that only a couple of consumers care about. Local fix at the display layer is the lowest-blast-radius option.
• Only fix the /g stateful regex and the symmetric strip, skip the remap. Addresses the flicker and the MERGED_<id>@… leak, but the dominant repro case is a personalDetails entry that is an optimistic stub with empty login and empty displayName. No amount of stripping recovers from that — only the accountID remap does.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-25 11:46:11 UTC.

Proposal

Replaces my earlier proposal. The previous body treated this as a current-account fallback in getDisplayNameOrDefault(). Layer 2 shows the failing records are keyed by the absorbed account's old accountID, so the fix needs to normalize that old ID before the shared report/search/archive display helpers run.

Please re-state the problem that we are trying to solve in this issue.

After Account B merges removed Account C, NewDot can open Account C's archived workspace expense chat under Account B. The chat header, search result, action/actor labels, and archive text should show the surviving primary login, but they resolve Account C's historical accountID as Hidden.

What is the root cause of that problem?

The workspace report and report actions still reference Account C's old accountID after the OldDot merge. The surviving primary login for Account B is available under Account B's account, but NewDot's display helpers look up the IDs that are still stored on the historical report/action rows.

That direct lookup collapses in the affected surfaces:

• getDisplayNameOrDefault() returns common.hidden when a personal-detail row has no usable displayName, default value, or login:

  App/src/libs/PersonalDetailsUtils.ts

  Lines 57 to 102 in e280509

  	function getDisplayNameOrDefault(
  	passedPersonalDetails?: Partial<PersonalDetails> | null,
  	defaultValue = '',
  	shouldFallbackToHidden = true,
  	shouldAddCurrentUserPostfix = false,
  	youAfterTranslation = youTranslation,
  	): string {
  	let displayName = passedPersonalDetails?.displayName ?? '';
  	let login = passedPersonalDetails?.login ?? '';
  	// If the displayName starts with the merged account prefix, remove it.
  	if (regexMergedAccount.test(displayName)) {
  	// Remove the merged account prefix from the displayName.
  	displayName = displayName.replaceAll(CONST.REGEX.MERGED_ACCOUNT_PREFIX, '');
  	}
  	// If the displayName is not set by the user, the backend sets the displayName same as the login so
  	// we need to remove the sms domain from the displayName if it is an sms login.
  	if (Str.isSMSLogin(login)) {
  	if (displayName === login) {
  	displayName = Str.removeSMSDomain(displayName);
  	}
  	login = Str.removeSMSDomain(login);
  	}
  	if (shouldAddCurrentUserPostfix && !!displayName) {
  	displayName = `${displayName} (${youAfterTranslation})`;
  	}
  	if (passedPersonalDetails?.accountID === CONST.ACCOUNT_ID.CONCIERGE) {
  	displayName = CONST.CONCIERGE_DISPLAY_NAME;
  	}
  	if (displayName) {
  	return displayName;
  	}
  	if (defaultValue) {
  	return defaultValue;
  	}
  	if (login) {
  	return login;
  	}
  	return shouldFallbackToHidden ? hiddenTranslation : '';

• getDisplayNameForParticipant() reads personalDetailsData?.[accountID] directly and returns an optimistic empty login or Hidden when the old merged-away ID has no usable detail:

  App/src/libs/ReportUtils.ts

  Lines 3302 to 3388 in e280509

  	function getPersonalDetailsForAccountID(accountID: number | undefined, personalDetailsData?: Partial<PersonalDetailsList>): Partial<PersonalDetails> {
  	if (!accountID) {
  	return {};
  	}
  	const defaultDetails = {
  	isOptimisticPersonalDetail: true,
  	};
  	if (!personalDetailsData) {
  	return allPersonalDetails?.[accountID] ?? defaultDetails;
  	}
  	return personalDetailsData?.[accountID] ?? defaultDetails;
  	}
  	/**
  	* Returns the personal details or a default object if the personal details are not available.
  	*/
  	function getPersonalDetailsOrDefault(personalDetails: Partial<PersonalDetails> | undefined | null): Partial<PersonalDetails> {
  	return personalDetails ?? {isOptimisticPersonalDetail: true};
  	}
  	const phoneNumberCache: Record<string, string> = {};
  	/**
  	* Get the displayName for a single report participant.
  	*/
  	function getDisplayNameForParticipant({
  	accountID,
  	shouldUseShortForm = false,
  	shouldFallbackToHidden = true,
  	shouldAddCurrentUserPostfix = false,
  	personalDetailsData = allPersonalDetails,
  	shouldRemoveDomain = false,
  	formatPhoneNumber,
  	}: {
  	accountID?: number;
  	shouldUseShortForm?: boolean;
  	shouldFallbackToHidden?: boolean;
  	shouldAddCurrentUserPostfix?: boolean;
  	personalDetailsData?: Partial<PersonalDetailsList>;
  	shouldRemoveDomain?: boolean;
  	formatPhoneNumber: LocaleContextProps['formatPhoneNumber'];
  	}): string {
  	if (!accountID) {
  	return '';
  	}
  	const personalDetails = getPersonalDetailsOrDefault(personalDetailsData?.[accountID]);
  	if (!personalDetails) {
  	return '';
  	}
  	const login = personalDetails.login ?? '';
  	// Check if the phone number is already cached
  	let formattedLogin = phoneNumberCache[login];
  	if (!formattedLogin) {
  	formattedLogin = formatPhoneNumber(login);
  	// Store the formatted phone number in the cache
  	phoneNumberCache[login] = formattedLogin;
  	}
  	// This is to check if account is an invite/optimistically created one
  	// and prevent from falling back to 'Hidden', so a correct value is shown
  	// when searching for a new user
  	if (personalDetails.isOptimisticPersonalDetail === true) {
  	return formattedLogin;
  	}
  	// For selfDM, we display the user's displayName followed by '(you)' as a postfix
  	const shouldAddPostfix = shouldAddCurrentUserPostfix && accountID === deprecatedCurrentUserAccountID;
  	let longName = getDisplayNameOrDefault(personalDetails, formattedLogin, shouldFallbackToHidden, shouldAddPostfix);
  	if (shouldRemoveDomain && longName === formattedLogin) {
  	longName = longName.split('@').at(0) ?? '';
  	}
  	// If the user's personal details (first name) should be hidden, make sure we return "hidden" instead of the short name
  	if (shouldFallbackToHidden && longName === hiddenTranslation) {
  	return longName;
  	}
  	const shortName = personalDetails.firstName ? personalDetails.firstName : longName;
  	return shouldUseShortForm ? shortName : longName;

• Policy expense chat names are based on report.ownerAccountID, which is the old account ID for the archived workspace chat. getPolicyExpenseChatName() also accepts personalDetailsList but does not pass it into getDisplayNameForParticipant(), so Search/OpenReport snapshot details can be ignored:

  App/src/libs/ReportNameUtils.ts

  Lines 294 to 305 in e280509

  	function getPolicyExpenseChatName({report, personalDetailsList}: {report: OnyxEntry<Report>; personalDetailsList?: Partial<PersonalDetailsList>}): string | undefined {
  	const ownerAccountID = report?.ownerAccountID;
  	const personalDetails = ownerAccountID ? personalDetailsList?.[ownerAccountID] : undefined;
  	const login = personalDetails ? personalDetails.login : null;
  	const reportOwnerDisplayName = getDisplayNameForParticipant({accountID: ownerAccountID, shouldRemoveDomain: true, formatPhoneNumber: formatPhoneNumberPhoneUtils}) || login;
  	if (reportOwnerDisplayName) {
  	return translateLocal('workspace.common.policyExpenseChatName', reportOwnerDisplayName);
  	}
  	return report?.reportName;

• The opened report header uses derived report attributes from computeReportName() / getReportName(), so the bad owner lookup becomes the visible title:

  App/src/libs/ReportNameUtils.ts

  Lines 883 to 1050 in e280509

  	function computeReportName({
  	report,
  	reports,
  	policies,
  	transactions,
  	allReportNameValuePairs,
  	personalDetailsList,
  	reportActions,
  	currentUserAccountID,
  	currentUserLogin,
  	allPolicyTags,
  	conciergeReportID,
  	reportAttributes,
  	}: ComputeReportName): string {
  	if (!report?.reportID) {
  	return '';
  	}
  	const reportPolicy = policies?.[`${ONYXKEYS.COLLECTION.POLICY}${report.policyID}`];
  	const parentReport = reports?.[`${ONYXKEYS.COLLECTION.REPORT}${report?.parentReportID}`];
  	const parentReportAction = isThread(report) ? reportActions?.[`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${report?.parentReportID}`]?.[report.parentReportActionID] : undefined;
  	const parentReportActionBasedName = computeReportNameBasedOnReportAction(
  	translateLocal,
  	formatPhoneNumberPhoneUtils,
  	parentReportAction,
  	report,
  	reportPolicy,
  	parentReport,
  	personalDetailsList,
  	reportAttributes,
  	);
  	if (parentReportActionBasedName) {
  	return parentReportActionBasedName;
  	}
  	if (report?.reportName && report.type === CONST.REPORT.TYPE.EXPENSE) {
  	return report?.reportName;
  	}
  	if (isActionOfType(parentReportAction, CONST.REPORT.ACTIONS.TYPE.CREATED_REPORT_FOR_UNAPPROVED_TRANSACTIONS)) {
  	const {originalID} = getOriginalMessage(parentReportAction) ?? {};
  	const originalReport = reports?.[`${ONYXKEYS.COLLECTION.REPORT}${originalID}`];
  	const reportName = computeReportName({
  	report: originalReport,
  	reports,
  	policies,
  	transactions,
  	allReportNameValuePairs,
  	personalDetailsList,
  	reportActions,
  	currentUserAccountID,
  	currentUserLogin,
  	conciergeReportID,
  	reportAttributes,
  	});
  	return getCreatedReportForUnapprovedTransactionsMessage(originalID, reportName, isOriginalReportDeleted(parentReportAction, originalReport), translateLocal);
  	}
  	if (isTaskReport(report)) {
  	const taskName = report?.reportName ?? '';
  	return Parser.isHTML(taskName) ? Parser.htmlToText(taskName).trim() : taskName.trim();
  	}
  	const privateIsArchivedValue = !!allReportNameValuePairs?.[`${ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS}${report.reportID}`]?.private_isArchived;
  	const policyTags = allPolicyTags?.[`${ONYXKEYS.COLLECTION.POLICY_TAGS}${report.policyID}`];
  	const chatThreadReportName = computeChatThreadReportName(
  	translateLocal,
  	privateIsArchivedValue,
  	report,
  	reports ?? {},
  	currentUserLogin ?? '',
  	parentReportAction,
  	policyTags,
  	reportPolicy,
  	transactions,
  	);
  	if (chatThreadReportName) {
  	return chatThreadReportName;
  	}
  	const transactionsArray = transactions ? (Object.values(transactions).filter(Boolean) as Array<OnyxEntry<Transaction>>) : undefined;
  	if (isClosedExpenseReportWithNoExpenses(report, transactionsArray)) {
  	return translateLocal('parentReportAction.deletedReport');
  	}
  	if (isGroupChat(report)) {
  	return getGroupChatName(formatPhoneNumberPhoneUtils, undefined, true, report) ?? '';
  	}
  	let formattedName: string | undefined;
  	if (isChatRoom(report)) {
  	formattedName = report?.reportName;
  	}
  	if (isPolicyExpenseChat(report)) {
  	formattedName = getPolicyExpenseChatName({report, personalDetailsList});
  	}
  	const policy = policies?.[`${ONYXKEYS.COLLECTION.POLICY}${report.policyID}`];
  	if (isMoneyRequestReport(report)) {
  	formattedName = getMoneyRequestReportName({report, policy});
  	}
  	if (isInvoiceReport(report)) {
  	const chatReport = reports?.[`${ONYXKEYS.COLLECTION.REPORT}${report?.chatReportID}`];
  	let chatReceiverPolicyID: string | undefined;
  	const chatReceiver = chatReport?.invoiceReceiver as unknown;
  	if (chatReceiver && typeof chatReceiver === 'object' && 'policyID' in chatReceiver) {
  	chatReceiverPolicyID = (chatReceiver as {policyID: string}).policyID;
  	}
  	const invoiceReceiverPolicy = chatReceiverPolicyID ? policies?.[`${ONYXKEYS.COLLECTION.POLICY}${chatReceiverPolicyID}`] : undefined;
  	formattedName = getInvoiceReportName(report, policy, invoiceReceiverPolicy);
  	}
  	if (isInvoiceRoom(report)) {
  	let receiverPolicyID: string | undefined;
  	const receiver = report?.invoiceReceiver as unknown;
  	if (receiver && typeof receiver === 'object' && 'policyID' in receiver) {
  	receiverPolicyID = (receiver as {policyID: string}).policyID;
  	}
  	const invoiceReceiverPolicy = receiverPolicyID ? policies?.[`${ONYXKEYS.COLLECTION.POLICY}${receiverPolicyID}`] : undefined;
  	formattedName = getInvoicesChatName({report, receiverPolicy: invoiceReceiverPolicy, personalDetails: personalDetailsList, currentUserAccountID, policy});
  	}
  	if (isSelfDM(report)) {
  	formattedName = getDisplayNameForParticipant({
  	accountID: report?.ownerAccountID,
  	shouldAddCurrentUserPostfix: true,
  	personalDetailsData: personalDetailsList,
  	formatPhoneNumber: formatPhoneNumberPhoneUtils,
  	});
  	}
  	if (isConciergeChatReport(report, conciergeReportID)) {
  	formattedName = CONST.CONCIERGE_DISPLAY_NAME;
  	}
  	const isArchivedNonExpense = isArchivedNonExpenseReport(report, privateIsArchivedValue);
  	if (formattedName) {
  	return formatReportLastMessageText(isArchivedNonExpense ? generateArchivedReportName(formattedName) : formattedName);
  	}
  	// Not a room or PolicyExpenseChat, generate title from first 5 other participants
  	formattedName = buildReportNameFromParticipantNames({report, personalDetailsList, currentUserAccountID});
  	const finalName = formattedName ?? report?.reportName ?? '';
  	return isArchivedNonExpense ? generateArchivedReportName(finalName) : finalName;
  	}
  	/**
  	* Returns the report name from OnyxDerived `reportAttributes` when available, falling back to the raw report object.
  	*
  	* **Always prefer passing `reportAttributesDerivedValue` from the derived Onyx key** (`ONYXKEYS.DERIVED.REPORT_ATTRIBUTES`).
  	* The fallback to `report.reportName` exists only for edge-cases where the derived value is not yet populated.
  	* Do NOT compute any part of the name here. Adjust `computeReportName` (internal) function if any change to report name are required.
  	*/
  	function getReportName(report?: Report, reportAttributesDerivedValue?: ReportAttributesDerivedValue['reports']): string {
  	if (!report?.reportID) {
  	return '';
  	}
  	return reportAttributesDerivedValue?.[report.reportID]?.reportName ?? report.reportName ?? '';

• Search action rows read data.personalDetailsList?.[reportAction.accountID] and compute reportName from the same report snapshot, so both the sender and the In <report name> text can inherit Hidden:

  App/src/libs/SearchUIUtils.ts

  Lines 2632 to 2663 in e280509

  	const from = reportAction.accountID ? (data.personalDetailsList?.[reportAction.accountID] ?? emptyPersonalDetails) : emptyPersonalDetails;
  	const report =
  	getReportOrDraftReport(reportID) ??
  	getReportOrDraftReport(reportAction.reportID) ??
  	data[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`] ??
  	data[`${ONYXKEYS.COLLECTION.REPORT}${reportAction.reportID}`] ??
  	{};
  	const policy = data[`${ONYXKEYS.COLLECTION.POLICY}${report.policyID}`] ?? {};
  	const originalMessage = isMoneyRequestAction(reportAction) ? getOriginalMessage<typeof CONST.REPORT.ACTIONS.TYPE.IOU>(reportAction) : undefined;
  	const isSendingMoney = isMoneyRequestAction(reportAction) && originalMessage?.type === CONST.IOU.REPORT_ACTION_TYPE.PAY && originalMessage?.IOUDetails;
  	const isReportArchived = isArchivedReport(data[`${ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS}${report.reportID}`]);
  	const invoiceReceiverPolicy: OnyxTypes.Policy | undefined =
  	report?.invoiceReceiver?.type === CONST.REPORT.INVOICE_RECEIVER_TYPE.BUSINESS ? data[`${ONYXKEYS.COLLECTION.POLICY}${report.invoiceReceiver.policyID}`] : undefined;
  	if (
  	!reportID ||
  	!isReportActionVisible(reportAction, reportID, canUserPerformWriteAction(report, isReportArchived), visibleReportActionsData) ||
  	isDeletedAction(reportAction) ||
  	isResolvedActionableWhisper(reportAction) ||
  	reportAction.actionName === CONST.REPORT.ACTIONS.TYPE.CLOSED ||
  	isCreatedAction(reportAction) ||
  	isWhisperActionTargetedToOthers(reportAction) ||
  	(isMoneyRequestAction(reportAction) && !!report?.isWaitingOnBankAccount && originalMessage?.type === CONST.IOU.REPORT_ACTION_TYPE.PAY && !isSendingMoney)
  	) {
  	continue;
  	}
  	reportActionItems.push({
  	...reportAction,
  	reportID,
  	from,
  	reportName: getSearchReportName({report, policy, personalDetails: data.personalDetailsList, transactions, invoiceReceiverPolicy, reports, isReportArchived}),
  	formattedFrom: from?.displayName ?? from?.login ?? '',

• The archive footer and LHN/search preview archive text resolve the closed action actor from personal details. In the removed-from-policy path this is why the text can become Hidden is no longer a member...:

  App/src/components/ArchivedReportFooter.tsx

  Lines 32 to 63 in e280509

  	const actorPersonalDetails = personalDetails?.[reportClosedAction?.actorAccountID ?? CONST.DEFAULT_NUMBER_ID];
  	let displayName = getDisplayNameOrDefault(actorPersonalDetails);
  	let oldDisplayName: string | undefined;
  	if (archiveReason === CONST.REPORT.ARCHIVE_REASON.ACCOUNT_MERGED) {
  	const newAccountID = originalMessage?.newAccountID;
  	const oldAccountID = originalMessage?.oldAccountID;
  	displayName = getDisplayNameOrDefault(personalDetails?.[newAccountID ?? CONST.DEFAULT_NUMBER_ID]);
  	oldDisplayName = getDisplayNameOrDefault(personalDetails?.[oldAccountID ?? CONST.DEFAULT_NUMBER_ID]);
  	}
  	const shouldRenderHTML = archiveReason !== CONST.REPORT.ARCHIVE_REASON.DEFAULT && archiveReason !== CONST.REPORT.ARCHIVE_REASON.BOOKING_END_DATE_HAS_PASSED;
  	let policyName = getPolicyName({report});
  	if (archiveReason === CONST.REPORT.ARCHIVE_REASON.INVOICE_RECEIVER_POLICY_DELETED) {
  	policyName = originalMessage?.receiverPolicyName ?? '';
  	}
  	if (shouldRenderHTML) {
  	oldDisplayName = lodashEscape(oldDisplayName);
  	displayName = lodashEscape(displayName);
  	policyName = lodashEscape(policyName);
  	}
  	const text = shouldRenderHTML
  	? translate(`reportArchiveReasons.${archiveReason}`, {
  	displayName: `<strong>${displayName}</strong>`,
  	oldDisplayName: `<strong>${oldDisplayName}</strong>`,
  	policyName: `<strong>${policyName}</strong>`,
  	shouldUseYou: actorPersonalDetails?.accountID === currentUserAccountID,
  	})

  and

  App/src/libs/OptionsListUtils/index.ts

  Lines 722 to 733 in e280509

  	if (isArchivedNonExpenseReport(report, isReportArchived)) {
  	const archiveReason =
  	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
  	(isClosedAction(lastOriginalReportAction) && getOriginalMessage(lastOriginalReportAction)?.reason) || CONST.REPORT.ARCHIVE_REASON.DEFAULT;
  	switch (archiveReason) {
  	case CONST.REPORT.ARCHIVE_REASON.ACCOUNT_CLOSED:
  	case CONST.REPORT.ARCHIVE_REASON.REMOVED_FROM_POLICY:
  	case CONST.REPORT.ARCHIVE_REASON.POLICY_DELETED: {
  	lastMessageTextFromReport = translate(`reportArchiveReasons.${archiveReason}`, {
  	displayName: formatPhoneNumberPhoneUtils(getDisplayNameOrDefault(lastActorDetails)),
  	policyName: getPolicyName({report, policy}),
  	});

The important point is that this is not just a string fallback problem for the current user's own accountID. In this repro the UI is often passed Account C's old ID, not Account B's current ID, so adding primaryLogin || session.email only when passedPersonalDetails.accountID === currentUserAccountID leaves the broken lookups untouched.

What changes do you think we should make in order to solve the problem?

Add a shared merged-account personal-details normalization step, then let the existing display surfaces render from the normalized data.

1. Add a helper near the personal-details/report display utilities that can synthesize aliases for absorbed account IDs. When a report/search payload is visible to the signed-in user as their own historical workspace expense chat, and the report still has an old ownerAccountID / action actor ID whose detail is missing, hidden, empty, or only a MERGED_<id>@ stub, add an entry keyed by that old account ID and populated from the surviving current user's primary detail (ACCOUNT.primaryLogin, SESSION.email, avatar/display name). Keep this alias limited to the signed-in user's merged historical identity.

2. Also support the explicit merge mapping when it is present on a closed action. OriginalMessageClosed already has oldAccountID and newAccountID for account-merged closures, so if a report action provides that mapping and personalDetailsList[newAccountID] exists, alias oldAccountID to the surviving detail before resolving names:

   App/src/types/onyx/OriginalMessage.ts

   Lines 275 to 290 in e280509

   	/** Model of `closed` report action */
   	type OriginalMessageClosed = {
   	/** Name of the policy */
   	policyName: string;
   	/** What was the reason to close the report */
   	reason: ValueOf<typeof CONST.REPORT.ARCHIVE_REASON>;
   	/** When was the message last modified */
   	lastModified?: string;
   	/** If the report was closed because accounts got merged, then this is the new account ID */
   	newAccountID?: number;
   	/** If the report was closed because accounts got merged, then this is the old account ID */
   	oldAccountID?: number;

3. Apply this normalization in the two data flows from the repro:

• OpenReport: before the response personal details are merged into ONYXKEYS.PERSONAL_DETAILS_LIST, synthesize the old-account alias for the opened report/report actions.
• SearchForReports: normalize the search response personalDetailsList before SearchUIUtils builds rows from data.personalDetailsList, because search rows use their own snapshot and can render before global Onyx has the alias.

4. Fix the local lookup bug in getPolicyExpenseChatName() by passing the supplied details through to getDisplayNameForParticipant():

const reportOwnerDisplayName = getDisplayNameForParticipant({
    accountID: ownerAccountID,
    shouldRemoveDomain: true,
    personalDetailsData: personalDetailsList,
    formatPhoneNumber: formatPhoneNumberPhoneUtils,
}) || login;

5. Keep the existing Hidden fallback for everyone else. If an account ID is not a known merged alias of the signed-in user and there is no explicit oldAccountID -> newAccountID mapping with visible surviving details, it should still render as hidden.

This fixes the header, search result, action/avatar actor labels, and archive text through one normalized identity path instead of patching each visible string independently.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

• computeReportName() for an archived policy expense chat whose ownerAccountID is an old merged-away account ID. With a normalized alias, the title should be <primary login>'s expenses (Archived), not Hidden's expenses.
• getPolicyExpenseChatName() should use its explicit personalDetailsList argument rather than falling back to only global Onyx details.
• ArchivedReportFooter or getLastMessageTextForReport() for a removed-from-policy archived report where the closed action actor is the old merged account ID. The archive text should use the surviving primary login/current-user identity.
• Search chat-result construction for report actions authored by the old merged account ID. The generated sender and report name should not contain Hidden when the search snapshot includes the normalized alias.
• A negative privacy test where an unrelated hidden account ID has no merged alias or explicit merge mapping; it should continue to render Hidden.

What alternative solutions did you explore? (Optional)

• A session-login fallback inside getDisplayNameOrDefault(). That is incomplete because the failing lookups are usually keyed by Account C's old ID, so the accountID === currentUserAccountID check does not fire.
• Only fixing the stateful MERGED_ACCOUNT_PREFIX regex or stripping the prefix from login. That can clean up prefixed strings, but it does not help when the old account's personal-details row is missing or intentionally empty.
• Remapping only from an ACCOUNT_MERGED closed action at render time. That helps reports carrying that exact archive reason, but the repro also involves removed-from-policy workspace archives and search snapshots. Normalizing the personal-details payload covers all affected consumers consistently.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @hoangzinh (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022058871801502762926

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

getDisplayNameOrDefault strips the MERGED_<accountID>@ prefix but doesn't recover the actual login — so when displayName is only the prefix (e.g. backend returns displayName: "MERGED_12345@" for the freshly-merged account's historical messages), the strip produces an empty string, falls through every fallback, and returns "Hidden":

https://github.com/Expensify/App/blob/main/src/libs/PersonalDetailsUtils.ts#L66-L100

if (regexMergedAccount.test(displayName)) {
    displayName = displayName.replaceAll(CONST.REGEX.MERGED_ACCOUNT_PREFIX, '');
}
...
if (displayName) {
    return displayName;
}
if (defaultValue) {
    return defaultValue;
}
if (login) {
    return login;
}
return shouldFallbackToHidden ? hiddenTranslation : '';

In the repro:

• Account B merges Account C.
• Backend rewrites C's historical personal details so displayName = "MERGED_<C_accountID>@<C_email>" to indicate the account is no longer canonical.
• When B re-enters the workspace, the report-actions still reference C's old accountID for messages that C sent before being removed.
• For those messages, passedPersonalDetails is C's record with displayName: "MERGED_<accountID>@<email>". After the strip, displayName becomes <email> — that's the correct path.

But there's a second pattern: when the merged account's login field on the personal details was cleared/nulled server-side (which happens when the account is fully consumed by the merge), and displayName was set to just MERGED_<accountID>@ with nothing after the @, the strip empties displayName, login is null/empty, and we hit hiddenTranslation.

regexMergedAccount is ^(MERGED_\d+@)/g — g flag with replaceAll and ^ anchor is correct, but it doesn't catch double-merged shapes like MERGED_111@MERGED_222@email (only strips the first prefix). The deeper issue is: the function has no fallback when stripping leaves nothing — it should fall back to the merged account's target login (the primary account it was merged into), not "Hidden".

There's also a likely backend angle: after the merge, the messages C sent should be re-attributed to B in report_actions. If that re-attribution isn't happening, the client is asked to display the merged-away account in its own messages.

What changes do you think we should make in order to solve the problem?

Two changes — recover from a strip-to-empty by reading the underlying login, and tighten the regex to handle nested merges:

1. In getDisplayNameOrDefault, preserve the email portion of the merged-account displayName instead of dropping to "Hidden" when the strip produces empty:

  function getDisplayNameOrDefault(
      passedPersonalDetails?: Partial<PersonalDetails> | null,
      defaultValue = '',
      shouldFallbackToHidden = true,
      shouldAddCurrentUserPostfix = false,
      youAfterTranslation = youTranslation,
  ): string {
      let displayName = passedPersonalDetails?.displayName ?? '';
      let login = passedPersonalDetails?.login ?? '';

      // If the displayName starts with the merged account prefix, remove it.
      if (regexMergedAccount.test(displayName)) {
-         displayName = displayName.replaceAll(CONST.REGEX.MERGED_ACCOUNT_PREFIX, '');
+         // Strip every MERGED_<id>@ prefix (handles nested merges) and recover the underlying
+         // login when the merged record's login field is empty.
+         let stripped = displayName;
+         while (regexMergedAccount.test(stripped)) {
+             stripped = stripped.replace(CONST.REGEX.MERGED_ACCOUNT_PREFIX, '');
+         }
+         displayName = stripped;
+         // If the stripped value looks like an email, use it as the fallback login too —
+         // this prevents Hidden when the personal details record had its login cleared.
+         if (!login && stripped.includes('@')) {
+             login = stripped;
+         }
      }

2. Add a regex that handles repeated prefixes in CONST/index.ts for clarity:

- MERGED_ACCOUNT_PREFIX: /^(MERGED_\d+@)/g,
+ MERGED_ACCOUNT_PREFIX: /^(MERGED_\d+@)+/g,

The + after the group strips one or more consecutive prefixes in a single pass — same effect as the while-loop fallback, but in regex.

With these in place:

• displayName: "MERGED_12345@accountc@example.com" → strips to accountc@example.com. Renders correctly.
• displayName: "MERGED_12345@MERGED_67890@user@example.com" → strips to user@example.com. Renders correctly.
• displayName: "MERGED_12345@", login: "" → strips to empty, falls through to login (empty), falls through to defaultValue, finally to hiddenTranslation. This path needs the backend to populate something — either displayName or login for the merged record. The client can't synthesize a name out of nothing.

What alternative solutions did you explore?

N/A