[$250] Dupes - Duplicates are not resolved if admin select "Keep selected" flow

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.4.0-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/folder/13176704/test-cases/41236827
Email or phone of affected tester (no customers): fischer9966+060526aadm@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: iPhone 17 Pro / 26.5. Google Pixel 5 / Android 14, MacOS 26.5 / Chrome, Safari
App Component: Money Requests

Action Performed:

1. Open Expensify App or go to https://staging.new.expensify.com
2. Login with new gmail.account
3. Create new collect workspace
4. Invite an employee
5. Login with employee
6. Submit 2 duplicate expenses in workspace chat
7. Login as Admin
8. Go to Workspace chat
9. Select any dupeicated Expense and click "Resolve duplicates"
10. Click "Keep selected" and follow the flow
11. Click "Confirm"

Expected Result:

Duplicated expenses are resolved if Admin select "Keep selected" flow

Actual Result:

Duplicated expenses are NOT resolved if Admin select "Keep selected" flow for expenses submitted by Employee

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7172956_1780688812848.iOS-dupes-not-resolved-by-Admin-keep-selected.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022063115322250052138
• Upwork Job ID: 2063115322250052138
• Last Price Increase: 2026-06-06

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

[godzillaxbox19982014-lgtm]

Proposal

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

All - Dupes - Duplicates are not resolved if admin select "Keep selected" flow

What is the root cause of that problem?

I traced this to the path that handles workspace name, expense report, TC:

• src/pages/iou/request/step/IOURequestStepSendFrom.tsx:65 (matching code path): }, [allPolicies, currentUserLogin, selectedWorkspace?.policyID, localeCompare, icons.FallbackWorkspaceAvatar]);
• src/libs/actions/IOU/Duplicate.ts:1329 (matching code path): export {getIOUActionForTransactions, mergeDuplicates, resolveDuplicates, duplicateExpenseTransaction, bulkDuplicateExpenses, duplicateReport, bulkDuplicateReports};
• src/pages/iou/request/step/confirmation/useExpenseSubmission.ts:398 (submitPerDiemExpense): function submitPerDiemExpense(selectedParticipantsArg: Participant[], trimmedComment: string, shouldHandleNav: boolean, policyRecentlyUsedCategoriesParam?: RecentlyUsedCategories) {
• The local evidence matches this recurring failure shape: optimistic transaction/report data is written to one Onyx key but the visible list reads another derived key. Here, src/pages/iou/request/step/IOURequestStepSendFrom.tsx:65 and src/libs/actions/IOU/Duplicate.ts:1329 do not agree on the same workspace name, expense report, TC value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/pages/iou/request/step/IOURequestStepSendFrom.tsx:65 to derive workspace name, expense report, TC from the report/transaction source that owns this flow before the value is consumed.
• Carry the same normalized value through src/libs/actions/IOU/Duplicate.ts:1329; that follows the safer family move to align optimistic/success/failure data with the selector consumed by the screen, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Reports, Expenses, IOU, Transactions surface and avoid changing payment actions, personal/deleted policies.

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

1. Add or update a regression in tests/unit/ReportUtils*.ts for the exact issue flow: All - Dupes - Duplicates are not resolved if admin select "Keep selected" flow.
2. Cover the counter-case near src/pages/iou/request/step/IOURequestStepSendFrom.tsx:65 so valid existing workspace name, expense report, TC behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep workspace name, expense report, TC consistent at the first read/write boundary shown above.

[MelvinBot]

Proposal

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

When an admin resolves duplicate expenses submitted by an employee via "Resolve duplicates" → "Keep selected" → "Confirm", nothing happens — the duplicates are not resolved. It works when the admin resolves their own duplicates. Regression on staging (v9.4.0-0), not yet in production.

Root Cause

The "Confirm" button routes non-owners (an admin reviewing someone else's expense) through resolveDuplicates, while report owners go through mergeDuplicates (Confirmation.tsx:200-204, branch on isReportOwner at :97). The merge path was untouched, which is why admin-resolving-own works but admin-resolving-employee fails.

PR #91194 (merged to main 2026-06-03 — on staging, not yet production) refactored resolveDuplicates and tightened the per-duplicate skip condition:

• Before: if (!iouAction) continue; — a duplicate was skipped only when no IOU action existed; it was still added to transactionIDList/reportActionIDList even if its transaction-thread report (childReportID) didn't exist yet.
• After: if (!transactionThreadReportID) continue; — a duplicate is now skipped whenever its childReportID is missing.

The new useTransactionThreadReportIDs hook returns undefined for any transaction whose IOU action has no childReportID (the PR even adds a test asserting this). When an admin reviews an employee's expense, those per-transaction thread reports are frequently not created/hydrated in the admin's session, so the map is undefined for every duplicate → the loop skips them all → transactionIDList and reportActionIDList are sent empty → the backend has nothing to resolve.

Reasonable solution

Don't drop a duplicate just because its childReportID isn't resolvable locally. In resolveDuplicates, still push the transactionID + generated hold reportActionID into resolvedTransactionIDList/reportActionIDList even when transactionThreadReportID is missing (only guard the optimistic Onyx hold-action write on a defined thread ID) — restoring the pre-PR behavior of sending the IDs to the backend. Alternatively, have the hook fall back to a generated/fetched thread report ID instead of returning undefined.

Verification status & what would confirm it

• Verified by code: the branching (isReportOwner), the tightened skip condition (PR Implement useTransactionThreadReportIDs hook and integrate it in resolveDuplicates function #91194 diff), and that empty arrays are sent when the map is empty.
• Not runtime-confirmed (no log/network access in this run). To confirm: on staging, inspect the ResolveDuplicates request payload (or backend logs) for an admin resolving an employee's duplicates and check whether transactionIDList/reportActionIDList are []. If they are, this is confirmed.
• Confidence: Medium-High — the code diff unambiguously changes behavior for the "IOU action exists but childReportID undefined" case, the timing matches staging-not-production, and it explains the employee-specific symptom.

Related issues

None found that duplicate this specific regression.

---

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

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-06 09:26:30 UTC.

Proposal

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

When an admin reviews a duplicate of an expense submitted by another member and goes through the "Keep selected" flow, clicking Confirm does not actually resolve the duplicates — the DUPLICATED_TRANSACTION violation comes back. The same flow works when the report owner resolves their own duplicates.

What is the root cause of that problem?

The Confirmation screen routes non-owners (an admin reviewing someone else's expense) through resolveDuplicates, while report owners go through mergeDuplicates:

if (!isReportOwner) {
    handleResolveDuplicates();   // admin → "hold" the other duplicates
    return;
}
handleMergeDuplicates();         // owner → delete the other duplicates

App/src/pages/TransactionDuplicate/Confirmation.tsx

Lines 198 to 205 in 380da60

	onPress={() => {
	isDismissingRef.current = true;
	if (!isReportOwner) {
	handleResolveDuplicates();
	return;
	}
	handleMergeDuplicates();
	}}

This is a regression from PR #91194 (merged 2026-06-03 → on staging, not yet production — which matches "Reproducible in staging?: Yes / production?: No"). That PR refactored resolveDuplicates and tightened the per-duplicate skip condition so a duplicate is now dropped whenever its transaction-thread report (childReportID) is missing:

for (const transactionID of params.transactionIDList) {
    const transaction = allTransactions[`${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`];
    if (!transaction) {
        continue;
    }
    const transactionThreadReportID = transactionThreadReportIDMap[transactionID];
    if (!transactionThreadReportID) {
        continue;   // ⬅️ duplicate dropped here BEFORE it is added to the server payload
    }
    ...
    resolvedTransactionIDList.push(transactionID);   // only reached if a thread existed
}

App/src/libs/actions/IOU/Duplicate.ts

Lines 481 to 529 in 380da60

	for (const transactionID of params.transactionIDList) {
	const transaction = allTransactions[`${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`];
	if (!transaction) {
	continue;
	}
	const transactionThreadReportID = transactionThreadReportIDMap[transactionID];
	if (!transactionThreadReportID) {
	continue;
	}
	const createdReportAction = buildOptimisticHoldReportAction();
	reportActionIDList.push(createdReportAction.reportActionID);
	resolvedTransactionIDList.push(transactionID);
	optimisticHoldTransactionActions.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`,
	value: {
	comment: {
	hold: createdReportAction.reportActionID,
	},
	},
	});
	failureHoldTransactionActions.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`,
	value: {
	comment: {
	hold: null,
	},
	},
	});
	optimisticHoldActions.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${transactionThreadReportID}`,
	value: {
	[createdReportAction.reportActionID]: createdReportAction,
	},
	});
	failureHoldActions.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${transactionThreadReportID}`,
	value: {
	[createdReportAction.reportActionID]: {
	errors: getMicroSecondOnyxErrorWithTranslationKey('iou.error.genericHoldExpenseFailureMessage'),
	},
	},
	});
	}

The map comes from useTransactionThreadReportIDs, which returns iouAction?.childReportID per duplicate. A transaction thread (childReportID) is created lazily — it doesn't exist until someone opens that expense. In the repro the admin resolves from the workspace chat without ever opening the member's individual expenses, so those duplicates have no childReportID → transactionThreadReportIDMap[transactionID] is undefined → every duplicate hits the continue. As a result resolvedTransactionIDList and reportActionIDList are sent empty:

const parameters: ResolveDuplicatesParams = {
    ...otherParams,
    transactionID: params.transactionID,
    reportActionIDList,                              // []
    transactionIDList: resolvedTransactionIDList,    // []
    dismissedViolationReportActionID: optimisticReportAction.reportActionID,
};
API.write(WRITE_COMMANDS.RESOLVE_DUPLICATES, parameters, {optimisticData, failureData});

The violation is removed optimistically (L454‑463), so it briefly looks resolved — but because the backend receives an empty transactionIDList it holds nothing, and the violation reappears on the next pull. That is exactly the "not resolved" symptom.

Why it works for the owner: mergeDuplicates deletes the other duplicates, so it never needs their threads; the only thread it needs (the kept transaction's, for the "resolved" action) already falls back to a generated ID — childReportID ?? generateReportID() — and is created optimistically (Confirmation.tsx L102‑111). resolveDuplicates holds the duplicates, needs each one's thread, and has no such fallback — it just skips.

Note on the "different category" observation: during staging repro it looked like identical expenses resolved while expenses that differed in a field (e.g. category) didn't. Both cases run the exact same resolveDuplicates code and send the same shaped payload, so the category value itself is not a code branch. The real determinant is whether the relevant transaction threads (childReportID) happen to be hydrated when Confirm is pressed:

• the held duplicate's thread — covered by the skip above, and
• the kept transaction's thread, used for the optimistic dismissed-violation action (L531) — which, when missing, writes to report_actions_undefined.

Going through the multi-step "choose which value to keep" wizard (only reachable when a field conflicts) changes which expense ends up being the "kept" one and which screens are visited, which is why thread hydration — and therefore the symptom — correlates with conflicting fields in practice. The fix below makes both threadless paths tolerant, so it covers the identical and the conflicting-field cases.

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

In resolveDuplicates (src/libs/actions/IOU/Duplicate.ts):

1. Stop dropping threadless held duplicates from the server payload. Push the transactionID + generated hold reportActionID into resolvedTransactionIDList / reportActionIDList and apply the comment.hold optimistic update before checking the thread. Only the optimistic Hold report action write is guarded behind a defined transactionThreadReportID (so we never corrupt report_actions_undefined):

const createdReportAction = buildOptimisticHoldReportAction();
reportActionIDList.push(createdReportAction.reportActionID);
resolvedTransactionIDList.push(transactionID);
// ...comment.hold optimistic + failure updates...

const transactionThreadReportID = transactionThreadReportIDMap[transactionID];
if (!transactionThreadReportID) {
    continue; // still sent to the backend above; just no optimistic thread action
}
// optimistic + failure Hold report action keyed on the thread

2. Guard the kept transaction's dismissed-violation action the same way. When the kept transaction's thread is missing, skip the optimistic action (the violation is still removed optimistically, and the backend records the dismissal from dismissedViolationReportActionID):

const keptTransactionThreadReportID = params.reportID ? getIOUActionForTransactions([params.transactionID], params.reportID).at(0)?.childReportID : undefined;
// ...
if (keptTransactionThreadReportID) {
    optimisticData.push(/* dismissed-violation action keyed on the thread */);
    failureData.push(/* rollback */);
}

This restores the pre-regression behavior (the IDs are always sent to the backend) while keeping Onyx clean, and mirrors the robustness the merge path already has.

What alternative solutions did you explore? (Optional)

• Generate a thread ID + build the optimistic thread for every missing thread (mirroring the merge path's buildTransactionThread + buildOptimisticCreatedReportAction): also correct, but heavier — it needs currentUserAccountID/currentUserLogin threaded into resolveDuplicates and adds success/failure cleanup for minted reports. The backend resolves each held transaction's thread from the transactionID itself (RESOLVE_DUPLICATES has no thread-id param), so minting one only affects optimistic display. The guarded approach above is the minimal, low-risk fix.
• Route admins through mergeDuplicates: wrong product behavior — an admin shouldn't delete another member's expenses; the "hold the rest" semantics of resolveDuplicates are intentional.
• Backfill the missing childReportID inside useTransactionThreadReportIDs: a read hook shouldn't mint report IDs / write side effects.

What specific scenario or edge case should we test for?

• Admin resolves an employee's duplicates from the workspace chat without opening the expenses (empty transactionThreadReportIDMap): the duplicates must be held and the violation must stay dismissed after a fresh pull. Regression-guarded by the strengthened should handle missing IOU actions gracefully test asserting transactionIDList/reportActionIDList are non-empty.
• Mix of existing + missing threads (handled per-transaction).
• Offline: failureData rolls back the violations/holds.

[melvin-bot]

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

[melvin-bot]

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

[aswin-s]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.