[Due for payment 2026-08-19] [$250] Merge expenses prompts for attendee selection even when both expenses have the same attendee

[m-natarajan]

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.20-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @coleaeason
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Create two expenses with the same attendee and same merchant.
2. Select one expense.
3. Initiate the Merge action.
4. Observe the Select the details you want to keep RHP

Expected Result:

If both expenses have the same attendee, the merge should proceed without prompting the user to choose an attendee.
The attendee should be retained automatically since there is no conflict.

Actual Result:

The merge flow prompts the user to select which attendee to keep, despite both expenses having the identical attendee.
This issue applies specifically to the Attendee field (not the Merchant field).

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

Recording.3100.mp4

View all open jobs on GitHub
ag

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022070504201552845271
• Upwork Job ID: 2070504201552845271
• Last Price Increase: 2026-07-10

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

What is the root cause of that problem?

The merge flow detects an attendee "conflict" using a different attendee list than the one it shows the user, so two expenses that look identical can still be flagged as conflicting.

When comment.attendees is empty on a transaction (common for card-imported / SmartScanned expenses), the UI still displays an attendee — the report owner — because the display path injects a default "report owner as attendee". But the conflict-detection path does not inject that default, so it sees an empty list [] instead.

Concretely, both paths call getTransactionDetails, but only one passes reportOwnerAsAttendee:

• Conflict detection — MergeTransactionUtils.ts:227-228 calls getTransactionDetails(targetTransaction) without the report owner.
• Display — MergeTransactionUtils.ts:592-593 calls it with targetReportOwnerAsAttendee / sourceReportOwnerAsAttendee.

The attendee comparison itself (MergeTransactionUtils.ts:290-303) then compares e.g. ["owner@email.com"] (the side that persisted the attendee) against [] (the side that relies on the injected default), deepEqual returns false, and attendees is pushed into conflictFields — even though the user sees the same attendee on both. This explains why merchant (a plain string compare) does not conflict but attendees does.

This is consistent with the call site in DetailsReviewPage.tsx:64-72, which computes targetReportOwnerAsAttendee / sourceReportOwnerAsAttendee and passes them to buildMergeFieldsData but not to getMergeableDataAndConflictFields.

Investigation details & evidence

• getAttendees only appends the report-owner default when a reportOwnerAsAttendee argument is provided (TransactionUtils/index.ts:1159-1166).
• getTransactionDetails forwards that argument into getAttendees (ReportUtils.ts:4805).
• The two getMergeableDataAndConflictFields call sites — DetailsReviewPage.tsx and ReceiptReviewPage.tsx, plus actions/MergeTransaction.ts — never pass the report-owner attendee, so the function can never inject the default.
• Secondary (lower-probability) factor: the comparison maps attendee.login ?? attendee.email without stripping the SMS domain, whereas the display string does (getAttendeesListDisplayString uses Str.removeSMSDomain, TransactionUtils/index.ts:1170-1182). For phone-login attendees, a suffixed login (...@expensify.sms) on one side vs a bare value on the other would also produce a false conflict.

Alternative explanations considered & ruled out: Two attendees added the same way via the selector store identical login/email values (MoneyRequestAttendeeSelector.tsx:113-126), so they would not conflict — the bug requires the asymmetric empty-vs-persisted case above, which is exactly what happens when merging a card/SmartScan expense (empty comment.attendees) with a manually created one.

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

Make conflict detection use the same attendee data the user sees:

1. Add targetReportOwnerAsAttendee / sourceReportOwnerAsAttendee parameters to getMergeableDataAndConflictFields and pass them into the two internal getTransactionDetails calls at MergeTransactionUtils.ts:227-228, mirroring what buildMergeFieldsData already does at lines 592-593.
2. Update the call sites to pass them: DetailsReviewPage.tsx (already computes both via useReportOwnerAsAttendee), ReceiptReviewPage.tsx, and actions/MergeTransaction.ts.
3. For robustness, normalize the SMS domain in the attendee comparison (e.g. apply Str.removeSMSDomain to the mapped login ?? email values) so phone-login attendees compare consistently with how they are displayed.

This guarantees that when both expenses resolve to the same attendee (whether explicitly stored or via the report-owner default), no attendee conflict is raised.

What alternative solutions did you explore? (Optional)

Only stripping the SMS domain in the comparison — rejected as insufficient on its own, because it does not address the primary empty-vs-persisted asymmetry that drives the reported repro.

Related issues

• Expensify/App#93151 — [Exploratory] Expense-Attendees section while merging expense in collect workspace (possibly related; touches the same merge-attendees area).

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94700) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[MobileMage]

Proposal

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

When merging two expenses that have the same attendee, the "Select the details you want to keep" step still lists Attendees as a conflicting field and forces the user to pick one, even though both options render the identical attendee. The Merchant field (and every other field) behaves correctly in the same scenario, so the bug is specific to how attendees are compared when deciding which fields conflict.

What is the root cause of that problem?

The merge flow decides which fields go on the "Select the details you want to keep" step in getMergeableDataAndConflictFields in MergeTransactionUtils.ts. Attendees have a dedicated comparison block that maps each attendee to attendee.login ?? attendee.email, sorts the logins, and only treats the field as resolved when the two login arrays are deepEqual; otherwise it pushes attendees into conflictFields.

App/src/libs/MergeTransactionUtils.ts

Lines 290 to 304 in d6e921f

	if (field === 'attendees') {
	const targetAttendeeLogins = ((targetValue as Attendee[] | undefined)?.map((attendee) => attendee.login ?? attendee.email) ?? [])
	.filter((login): login is string => !!login)
	.sort(localeCompare);
	const sourceAttendeeLogins = ((sourceValue as Attendee[] | undefined)?.map((attendee) => attendee.login ?? attendee.email) ?? [])
	.filter((login): login is string => !!login)
	.sort(localeCompare);
	if (deepEqual(targetAttendeeLogins, sourceAttendeeLogins)) {
	mergeableData[field] = isTargetValueEmpty ? sourceValue : targetValue;
	} else {
	conflictFields.push(field);
	}
	continue;
	}

The values fed into this block come from getTransactionDetails(targetTransaction) and getTransactionDetails(sourceTransaction), both called WITHOUT a reportOwnerAsAttendee argument (lines 227-228). So for an expense that has no explicit attendees stored, getAttendees returns []. The asymmetry is that the DISPLAY path does the opposite: buildMergeFieldsData calls getTransactionDetails(..., targetReportOwnerAsAttendee) / (..., sourceReportOwnerAsAttendee), where useReportOwnerAsAttendee resolves the report creator and getAttendees default-fills empty attendees with that creator. The net result: when one expense stores the creator in comment.attendees and the other has empty attendees (a very common state, e.g. one expense created through a flow that persisted the default attendee and the other that didn't), the comparison sees ["me@x.com"] vs [], while the UI default-fills both options to the same creator. The user sees two identical attendees but is still forced to choose.

I reproduced this with the exact normalize/compare logic from the codebase. ["me@x.com"] vs [] evaluates to equal: false, so attendees is pushed to conflictFields. The underlying gap is that the attendees block lacks the empty-tolerance that every other field gets. The generic branch resolves the field whenever one side is empty:

if (isTargetValueEmpty || isSourceValueEmpty || targetValue === sourceValue) { ... }

but the attendees block only checks deepEqual(targetAttendeeLogins, sourceAttendeeLogins) and ignores isTargetValueEmpty / isSourceValueEmpty, which are already computed in scope at lines 234-235.

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

In the attendees block, mirror the generic branch's empty-tolerance so an empty-vs-populated pair auto-resolves to the populated side (which is exactly what the UI already default-fills and displays). The isTargetValueEmpty / isSourceValueEmpty flags are already available, so we only need to widen the condition at line 298:

if (isTargetValueEmpty || isSourceValueEmpty || deepEqual(targetAttendeeLogins, sourceAttendeeLogins)) {
    mergeableData[field] = isTargetValueEmpty ? sourceValue : targetValue;
} else {
    conflictFields.push(field);
}

App/src/libs/MergeTransactionUtils.ts

Lines 298 to 302 in d6e921f

	if (deepEqual(targetAttendeeLogins, sourceAttendeeLogins)) {
	mergeableData[field] = isTargetValueEmpty ? sourceValue : targetValue;
	} else {
	conflictFields.push(field);
	}

This is safe and narrowly scoped. When both sides have real (and identical) attendees, the deepEqual path is unchanged. When attendees genuinely differ, the block still pushes to conflictFields. The only new behavior is the empty case, where we keep the non-empty attendee list — which already matches the creator the UI shows on both options, so nothing is silently dropped. It uses flags already computed for every other field, keeping attendees consistent with how merchant/category/etc. handle one-sided emptiness.

What alternative solutions did you explore? (Optional)

I considered making getMergeableDataAndConflictFields pass each transaction's reportOwnerAsAttendee into getTransactionDetails so the comparison default-fills the creator the same way the display does. That works conceptually but is heavier: it requires threading two personal-detail lookups (or the hook results) into a pure util used by both the action and the page, and it changes the comparison for every field rather than fixing the attendee-specific gap. The empty-tolerance fix is smaller and matches the existing pattern used by all other fields.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The merge flow computes the conflicting fields with getMergeableDataAndConflictFields, and the attendees field gets a dedicated branch that compares the two transactions' attendee logins:

App/src/libs/MergeTransactionUtils.ts

Lines 290 to 304 in b396890

	if (field === 'attendees') {
	const targetAttendeeLogins = ((targetValue as Attendee[] | undefined)?.map((attendee) => attendee.login ?? attendee.email) ?? [])
	.filter((login): login is string => !!login)
	.sort(localeCompare);
	const sourceAttendeeLogins = ((sourceValue as Attendee[] | undefined)?.map((attendee) => attendee.login ?? attendee.email) ?? [])
	.filter((login): login is string => !!login)
	.sort(localeCompare);
	if (deepEqual(targetAttendeeLogins, sourceAttendeeLogins)) {
	mergeableData[field] = isTargetValueEmpty ? sourceValue : targetValue;
	} else {
	conflictFields.push(field);
	}
	continue;
	}

The attendee values come from getTransactionDetails, which derives them through getAttendees. The key detail is in getAttendees: when a transaction's raw comment.attendees is empty, the attendee shown to the user is not stored on the transaction — it's the report owner (you), injected on the fly only when a reportOwnerAsAttendee argument is passed:

App/src/libs/TransactionUtils/index.ts

Lines 1159 to 1167 in b396890

	function getAttendees(transaction: OnyxInputOrEntry<Transaction>, reportOwnerAsAttendee?: Attendee): Attendee[] {
	const rawAttendees = transaction?.modifiedAttendees ?? transaction?.comment?.attendees;
	const attendees = normalizeAttendees(convertAttendeesToArray(rawAttendees));
	if (attendees.length === 0 && reportOwnerAsAttendee !== undefined) {
	attendees.push(reportOwnerAsAttendee);
	}
	return attendees;
	}

Now look at the asymmetry between the two consumers:

• The display builder passes the report owner into getTransactionDetails, so each row renders the injected self-attendee — buildMergeFieldsData:

  const targetTransactionDetails = getTransactionDetails(targetTransaction, undefined, undefined, undefined, undefined, targetReportOwnerAsAttendee);
  const sourceTransactionDetails = getTransactionDetails(sourceTransaction, undefined, undefined, undefined, undefined, sourceReportOwnerAsAttendee);

• The conflict-detection builder calls getTransactionDetails with no report owner (its signature doesn't even accept one) — lines 227-228:

  const targetTransactionDetails = getTransactionDetails(targetTransaction);
  const sourceTransactionDetails = getTransactionDetails(sourceTransaction);

So a transaction whose attendee is the default (empty raw comment.attendees) yields [] in the conflict comparison, while the same transaction renders the self-attendee in the UI. The moment the two merged expenses don't store the attendee identically — one has the self-attendee persisted in comment.attendees and the other relies on the default — the conflict path compares ['you@x.com'] vs [], deepEqual returns false, and attendees is pushed into conflictFields, while the display (which injects the owner on both sides) shows the exact same attendee.

So: display injects reportOwnerAsAttendee and shows identical attendees → conflict detection omits it, so the default self-attendee is read as [] → deepEqual mismatch → attendees flagged as a conflict → user is wrongly prompted to choose. Merchant is unaffected because it's a plain stored string compared by === at line 306, with no owner-injection layer.

Note the .sort(localeCompare) on lines 293/296 is not the cause — localeCompare is (a, b) => number (LocaleContextProvider) and Array.prototype.sort invokes it as (a, b), so the sort is correct. The defect is the missing report-owner injection, and it exists at all three call sites of getMergeableDataAndConflictFields: DetailsReviewPage, ReceiptReviewPage, and the MergeTransaction action (the action is what runs first on "Merge" and decides whether to skip straight to confirmation).

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

Make conflict detection inject the report owner exactly like the display path already does. Add targetReportOwnerAsAttendee / sourceReportOwnerAsAttendee params to getMergeableDataAndConflictFields and forward them to its two getTransactionDetails calls, mirroring buildMergeFieldsData lines 592-593:

const targetTransactionDetails = getTransactionDetails(targetTransaction, undefined, undefined, undefined, undefined, targetReportOwnerAsAttendee);
const sourceTransactionDetails = getTransactionDetails(sourceTransaction, undefined, undefined, undefined, undefined, sourceReportOwnerAsAttendee);

Then thread the owner in at every call site, reusing the existing useReportOwnerAsAttendee hook:

• DetailsReviewPage already computes targetReportOwnerAsAttendee / sourceReportOwnerAsAttendee (already passed to buildMergeFieldsData) — just pass them into the conflict call too.
• ReceiptReviewPage adds the same hook calls and passes them in.
• The non-React MergeTransaction action resolves them via the same underlying utils the hook uses — getReportOwnerAccountIDAsAttendee + getReportOwnerAsAttendee — and passes them in.

With the owner injected on both sides, two expenses showing the same attendee produce identical login arrays, deepEqual returns true, attendees stays out of conflictFields, and the flow skips the prompt — keeping the conflict logic and the display perfectly in sync (which is also the correct fix for the inverse case where they currently disagree). Minor changes/improvements can be discussed in the PR phase.

What alternative solutions did you explore? (Optional)

Special-case the attendees branch alone: when both transactions have empty raw comment.attendees, treat them as equal without injecting the owner. This patches the most common path but leaves conflict detection and display reading attendees through two different code paths, so any case where only one side has an empty list (default vs explicitly-persisted self) would still diverge. Threading reportOwnerAsAttendee through getMergeableDataAndConflictFields is cleaner because it makes the two paths derive attendees identically by construction.

[dilshodmackbook-sketch]

Proposal

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

Merging two expenses that have the same attendee still shows the Attendees field on the "Select the details you want to keep" RHP, forcing the user to pick an attendee even though there is no conflict. The Merchant field behaves correctly in the same scenario.

What is the root cause of that problem?

Conflict detection and the RHP display resolve attendees differently, so the two paths disagree about whether the attendees match.

When a transaction has no explicit attendees stored, getAttendees falls back to the report owner as the default attendee — but only when a reportOwnerAsAttendee argument is provided:

App/src/libs/TransactionUtils/index.ts

Lines 1159 to 1167 in 7f3e84e

	function getAttendees(transaction: OnyxInputOrEntry<Transaction>, reportOwnerAsAttendee?: Attendee): Attendee[] {
	const rawAttendees = transaction?.modifiedAttendees ?? transaction?.comment?.attendees;
	const attendees = normalizeAttendees(convertAttendeesToArray(rawAttendees));
	if (attendees.length === 0 && reportOwnerAsAttendee !== undefined) {
	attendees.push(reportOwnerAsAttendee);
	}
	return attendees;
	}

The merge display path passes that fallback through getTransactionDetails, so both expenses render the report owner:

App/src/libs/MergeTransactionUtils.ts

Lines 592 to 593 in 7f3e84e

	const targetTransactionDetails = getTransactionDetails(targetTransaction, undefined, undefined, undefined, undefined, targetReportOwnerAsAttendee);
	const sourceTransactionDetails = getTransactionDetails(sourceTransaction, undefined, undefined, undefined, undefined, sourceReportOwnerAsAttendee);

But the conflict-detection path calls getTransactionDetails without it:

App/src/libs/MergeTransactionUtils.ts

Lines 227 to 228 in 7f3e84e

	const targetTransactionDetails = getTransactionDetails(targetTransaction);
	const sourceTransactionDetails = getTransactionDetails(sourceTransaction);

So in getMergeableDataAndConflictFields the attendee comparison never applies the report-owner fallback. When one expense stores the attendee explicitly (e.g. [owner]) and the other relies on the implicit default ([]), the two login lists differ and the field is pushed into conflictFields:

App/src/libs/MergeTransactionUtils.ts

Lines 290 to 304 in 7f3e84e

	if (field === 'attendees') {
	const targetAttendeeLogins = ((targetValue as Attendee[] | undefined)?.map((attendee) => attendee.login ?? attendee.email) ?? [])
	.filter((login): login is string => !!login)
	.sort(localeCompare);
	const sourceAttendeeLogins = ((sourceValue as Attendee[] | undefined)?.map((attendee) => attendee.login ?? attendee.email) ?? [])
	.filter((login): login is string => !!login)
	.sort(localeCompare);
	if (deepEqual(targetAttendeeLogins, sourceAttendeeLogins)) {
	mergeableData[field] = isTargetValueEmpty ? sourceValue : targetValue;
	} else {
	conflictFields.push(field);
	}
	continue;
	}

The user sees the same attendee on both sides (because the display fills in the report owner) yet is still prompted to choose, since detection compared [owner] against [].

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

Make conflict detection resolve attendees the same way the display does, by threading the report-owner fallback into getMergeableDataAndConflictFields.

Add the two attendees to the signature and forward them to the existing getTransactionDetails calls (src/libs/MergeTransactionUtils.ts):

function getMergeableDataAndConflictFields(
    targetTransaction,
    sourceTransaction,
    localeCompare,
    getCurrencyDecimals,
    searchReports = [],
    targetTransactionPolicy,
    sourceTransactionPolicy,
    targetReportOwnerAsAttendee,
    sourceReportOwnerAsAttendee,
) {
    ...
    const targetTransactionDetails = getTransactionDetails(targetTransaction, undefined, undefined, undefined, undefined, targetReportOwnerAsAttendee);
    const sourceTransactionDetails = getTransactionDetails(sourceTransaction, undefined, undefined, undefined, undefined, sourceReportOwnerAsAttendee);

Then pass the report-owner attendees at the two call sites:

• In DetailsReviewPage the values are already computed (targetReportOwnerAsAttendee/sourceReportOwnerAsAttendee) and handed to buildMergeFieldsData; pass the same two into getMergeableDataAndConflictFields so detection and display agree:

App/src/pages/TransactionMerge/DetailsReviewPage.tsx

Lines 64 to 72 in 7f3e84e

	const {conflictFields: detectedConflictFields, mergeableData} = getMergeableDataAndConflictFields(
	targetTransaction,
	sourceTransaction,
	localeCompare,
	getCurrencyDecimals,
	[targetTransactionReport, sourceTransactionReport],
	targetTransactionPolicy,
	sourceTransactionPolicy,
	);

• In the setupMergeTransactionDataAndNavigate action (which uses the result to skip the RHP when there are no conflicts) derive each transaction's report owner via getReportOwnerAsAttendee(getReportOwnerAccountIDAsAttendee(...)) from personal details and pass them in too:

App/src/libs/actions/MergeTransaction.ts

Lines 105 to 113 in 7f3e84e

	const {conflictFields, mergeableData} = getMergeableDataAndConflictFields(
	targetTransaction,
	sourceTransaction,
	localeCompare,
	getCurrencyDecimals,
	searchReports,
	targetTransactionPolicy,
	sourceTransactionPolicy,
	);

With both paths normalizing the implicit attendee to the report owner, the login lists match and attendees is no longer flagged as a conflict when the attendee is actually the same.

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

In a getMergeableDataAndConflictFields unit test, assert that attendees is NOT in conflictFields when one transaction stores the attendee explicitly and the other has no attendees but resolves to the same report owner via reportOwnerAsAttendee, and that it IS flagged when the two resolve to genuinely different attendees.

What alternative solutions did you explore? (Optional)

Skip the attendee fallback entirely and compare only explicitly-stored attendees (treat empty as empty) in both detection and display. This also removes the false conflict, but it diverges from how attendees are shown everywhere else in the app (where the report owner is the implicit default), so an expense with an explicit self-attendee and one with the implicit self-attendee would still be treated as different — only hidden because both display empty. Aligning detection with the existing display fallback is more consistent.

[mukhrr]

Proposal

What is the root cause of that problem?

The merge flow determines attendee conflicts using only attendee.login ?? attendee.email:

App/src/libs/MergeTransactionUtils.ts

Lines 290 to 301 in 1e18e85

	if (field === 'attendees') {
	const targetAttendeeLogins = ((targetValue as Attendee[] | undefined)?.map((attendee) => attendee.login ?? attendee.email) ?? [])
	.filter((login): login is string => !!login)
	.sort(localeCompare);
	const sourceAttendeeLogins = ((sourceValue as Attendee[] | undefined)?.map((attendee) => attendee.login ?? attendee.email) ?? [])
	.filter((login): login is string => !!login)
	.sort(localeCompare);
	if (deepEqual(targetAttendeeLogins, sourceAttendeeLogins)) {
	mergeableData[field] = isTargetValueEmpty ? sourceValue : targetValue;
	} else {
	conflictFields.push(field);

That is not the canonical attendee identity. Other attendee-related logic prefers accountID when it is available, and only falls back to login/email when it is not. For example, missing-attendee validation filters by accountID when ownerAccountID is known:

App/src/libs/Violations/ViolationsUtils.ts

Lines 594 to 608 in 1e18e85

	// Calculate attendees minus owner. When ownerAccountID is known, filter by accountID.
	// When ownerAccountID is undefined (offline split where iouReport is unavailable),
	// fallback to using login/email to identify the owner (similar to AttendeeUtils approach).
	let attendeesMinusOwnerCount: number;
	if (ownerAccountID !== undefined) {
	// Normal case: filter by accountID
	attendeesMinusOwnerCount = attendees.filter((a) => a?.accountID !== ownerAccountID).length;
	} else {
	// Offline scenario: ownerAccountID unavailable, use login/email as fallback
	const currentUserEmail = getCurrentUserEmail();
	if (currentUserEmail) {
	// Filter by login or email to identify owner
	attendeesMinusOwnerCount = attendees.filter((a) => {
	const attendeeIdentifier = a?.login ?? a?.email;
	return attendeeIdentifier !== currentUserEmail;

The attendee selector also treats accountID as the primary list identity:

App/src/pages/iou/request/MoneyRequestAttendeeSelector.tsx

Lines 85 to 94 in 1e18e85

	const initialSelectedOptions = sortAlphabetically([...attendees], 'displayName', localeCompare).map((attendee) => ({
	...attendee,
	reportID: CONST.DEFAULT_NUMBER_ID.toString(),
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	keyForList: String(attendee.accountID) || attendee.email || attendee.displayName,
	selected: true,
	// Use || to fall back to displayName for name-only attendees (empty email)
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	login: attendee.email || attendee.displayName,
	...getPersonalDetailByEmail(attendee?.email),

So two attendee objects can represent the same person by accountID, but still be considered different by the merge conflict detector if their login/email shape differs. That makes getMergeableDataAndConflictFields() add attendees to conflictFields, so the details review RHP asks the user to choose an attendee even though there is no real attendee conflict.

History note: commit e16da652e5f638d89b059b636564b1b9db51a17c changed this merge attendee logic while removing personal-details hydration from attendees. It made the attendee check rely only on the derived login arrays, which is where this identity mismatch comes from:
e16da65

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

Normalize attendee identity before comparing attendees in getMergeableDataAndConflictFields().

Use accountID first, then fallback to normalized login/email, then display name only for name-only attendees. Prefix the key type so an account ID cannot collide with a numeric-looking login/display name.

Small diff sketch:

+function getAttendeeMergeIdentity(attendee: Attendee): string {
+    if (attendee.accountID !== undefined) {
+        return `accountID:${attendee.accountID}`;
+    }
+
+    const loginOrEmail = attendee.login ?? attendee.email;
+    if (loginOrEmail) {
+        return `login:${loginOrEmail.trim().toLowerCase()}`;
+    }
+
+    return `name:${attendee.displayName.trim().toLowerCase()}`;
+}
+
+function getAttendeeMergeIdentities(attendees: Attendee[] | undefined, localeCompare: LocaleContextProps['localeCompare']): string[] {
+    return (attendees ?? []).map(getAttendeeMergeIdentity).filter(Boolean).sort(localeCompare);
+}

Then replace the current login-only comparison:

-const targetAttendeeLogins = ((targetValue as Attendee[] | undefined)?.map((attendee) => attendee.login ?? attendee.email) ?? [])
-    .filter((login): login is string => !!login)
-    .sort(localeCompare);
-const sourceAttendeeLogins = ((sourceValue as Attendee[] | undefined)?.map((attendee) => attendee.login ?? attendee.email) ?? [])
-    .filter((login): login is string => !!login)
-    .sort(localeCompare);
+const targetAttendeeIdentities = getAttendeeMergeIdentities(targetValue as Attendee[] | undefined, localeCompare);
+const sourceAttendeeIdentities = getAttendeeMergeIdentities(sourceValue as Attendee[] | undefined, localeCompare);

-if (deepEqual(targetAttendeeLogins, sourceAttendeeLogins)) {
+if (deepEqual(targetAttendeeIdentities, sourceAttendeeIdentities)) {
     mergeableData[field] = isTargetValueEmpty ? sourceValue : targetValue;
 } else {
     conflictFields.push(field);
 }

To avoid regressions, keep the existing behavior that attendee order does not matter by sorting identities before comparison, keep login/email fallback for optimistic or unknown attendees, and add tests for:

1. Same accountID, different login/email shape: no attendee conflict.
2. Different accountID: attendee conflict.
3. Same login/email with no accountID: no attendee conflict.
4. Different name-only attendees: attendee conflict.

What alternative solutions did you explore? (Optional)

We could compare attendee display strings, but that would be weaker because display names are not unique and can change. We could deep-compare the full attendee objects, but that would create false conflicts from irrelevant fields like avatar, text, selected state, or hydrated personal-detail metadata. A normalized identity comparison matches the existing attendee patterns and keeps the change scoped to merge conflict detection.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-26 13:59:33 UTC.

Proposal

What is the root cause of that problem?

The merge flow decides whether to show the details-selection page in getMergeableDataAndConflictFields(). For attendees, that function currently compares only each stored attendee's login ?? email, and it builds those values from getTransactionDetails() without the report-owner fallback attendee.

Other attendee display paths do not use that same shape. The expense row and merge details page can treat the report owner as the effective attendee when the stored attendee list is empty, and the details page formats attendees from display name/login. So two expenses can show the same attendee, but the conflict detector still sees different raw values, such as an empty attendee list on one expense and an explicit attendee object for the same person on the other. It then adds attendees to conflictFields, and the details page renders two identical attendee choices.

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

Update the attendee branch in getMergeableDataAndConflictFields() to compare effective attendee identities instead of only raw login ?? email values.

I would add a small helper in MergeTransactionUtils that builds the attendee list the merge flow should compare, including the same report-owner fallback used by attendee display when a transaction has no stored attendees. Then compare stable normalized keys for each attendee:

• prefer accountID when present;
• otherwise use a normalized login/email value, including case/SMS-domain normalization;
• otherwise fall back to a trimmed normalized display name for name-only attendees.

Sort those keys and compare the two arrays. If they match, keep attendees out of conflictFields and set mergeableData.attendees to the explicit target/source attendee value, or to the effective fallback value when needed so the merged expense still retains the attendee. If they differ, keep the current conflict behavior.

Thread the target/source report-owner attendee, or the data needed to build it, through every getMergeableDataAndConflictFields() caller in the merge flow: initial merge navigation, receipt review, details review, and source-selection confirmation. This stays in the App merge UI/data-normalization layer and does not change the backend request contract or unrelated merge fields like merchant, amount, category, or report.

Add regression coverage for:

• one expense with an empty stored attendee list that displays the report owner and another expense with that same attendee stored explicitly;
• two attendee objects with the same accountID but different login/email population;
• genuinely different attendees still producing an attendees conflict;
• the receipt-review/direct navigation paths continuing to skip details when attendee identities match.

What alternative solutions did you explore? (Optional)

I considered comparing only the rendered attendee display string, but two different people can share a display name. I also considered hiding duplicate-looking attendee rows in the details page, but that would leave mergeableData.attendees unresolved and would not fix the route decision. Comparing effective attendee identities in the merge detector fixes the data decision at the source.

[melvin-bot]

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

[kitvasyl]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.