Expense-Scan 1:1 expense shows review duplicate briefly and disappears.

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: V9.4.73-3
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176877/test-cases/41237365
Email or phone of affected tester (no customers): dreamnitethedragon+vegst@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Redmi note 10s android 13
App Component: Money Requests

Action Performed:

1. Launch app
2. Go to self dm
3. Create 2 scan expense with below receipt
4. After scan completes , submit to a friend selecting two different 1:1 user
5. Go to spend - expense - open 2 scan 1:1 expense

Expected Result:

Scan 1:1 expense must not show review duplicate briefly and disappears.

Actual Result:

Scan 1:1 expense shows review duplicate briefly and disappears.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

_

Bug7254318_1788879255655.Screenrecorder-2026-09-08-20-12-27-794.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7254318

Issue Owner

Current Issue Owner: @yusufdeveloper2903

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

[MelvinBot]

Proposal

What is the root cause of that problem?

The duplicatedTransaction violation is only ever set by the backend — the App never computes it (src/libs/Violations/ViolationsUtils.ts:1012 is a translation case only). When you submit a self‑DM scan to a 1:1 recipient, the convert path clears that violation optimistically only and never re‑asserts it on success, so a server payload puts it right back for a moment.

Two gaps combine:

1. No successData counterpart on the convert path. getDeleteTrackExpenseInformation pushes an optimistic SET null at TrackExpense.ts:747-751 and a failure restore at :816-820, but no success entry — the successData types at :778 and :1250 can't even hold a violations key. Since OnyxUpdates.ts:59-71 applies response.onyxData before successData, any stale echoed violation wins. This exact failure mode is already documented as the reason the other path added a success re‑assert — see the comment at TransactionUtils/index.ts:2978-2986.

2. The sibling expense is never pruned. removeTransactionFromDuplicateTransactionViolation is wired into delete and update, but not into TrackExpense.ts. So the second scan keeps a one‑sided duplicates: [T1] pointing at an expense that has moved away.

The button itself has no guard that would hide the flash: it is a pure function of the violation's presence (ReportPrimaryActionUtils.ts:360-390), isDuplicate never validates that data.duplicates still resolves to real, same‑report transactions (TransactionUtils/index.ts:2415-2441), and the violations hook discards useOnyx loading status behind an empty‑array default (useTransactionViolations.ts:21) — so "loading" and "no violations" are indistinguishable.

Step 5 of the repro (Spend → Expenses) adds a second trigger with no server involvement at all: opening from Search merges snapshot‑era violations straight back into live Onyx at Report/index.ts:1877-1885, then OpenReport's response overwrites them.

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

Mirror what the move‑expense path already does correctly in Transaction.ts:1242-1253:

1. In getDeleteTrackExpenseInformation / getConvertTrackedExpenseInformation, add a successData entry that re‑asserts transactionViolations_<transactionID> = null alongside the existing optimistic SET. Widen the successData type unions at TrackExpense.ts:778 and :1250 to include TRANSACTION_VIOLATIONS.
2. Call removeTransactionFromDuplicateTransactionViolation on the convert path so the sibling scan's duplicates list drops the moved transaction (with optimistic + success + failure entries, as that helper already builds).
3. Make isDuplicate validate the duplicate set before showing the action — resolve data.duplicates and require them to still exist and be reviewable, the way TransactionPreview/index.tsx:64-68 already does. This makes the header robust to any stale one‑sided violation, not just this flow.

Item 3 alone stops the flash; items 1 and 2 fix the stale data that causes it.

What alternative solutions did you explore? (Optional)

Alternatives considered and evidence

Gate the button on violations having loaded. Threading useOnyx status through useTransactionViolations would suppress the flash, but it hides the real problem (bad persisted data) and would delay the button in the legitimate duplicate case. Rejected in favour of item 3.

Recompute violations for the destination report. Not viable — buildOnyxDataForMoneyRequest deliberately skips violation computation off group policies (MoneyRequestBuilder.ts:1129-1132), and duplicatedTransaction is server‑only anyway.

Could the backend legitimately still flag these as duplicates? Possible, and I could not rule it out — the VictoriaLogs tooling was unavailable in this run, so there is no production confirmation of which payload re‑adds the violation (the convert response, the follow‑up OpenReport, or a later push). Either way the App‑side fix is the same shape, since the button should not appear for a duplicate set that no longer resolves. If a Contributor+ wants that confirmed first, the check is whether ConvertTrackedExpenseToRequest echoes duplicatedTransaction for the moved transaction.

Why the asymmetry exists. Expensify/App#95994 added exactly this cleanup for moves into the self‑DM, but gated it behind if (isUnreported) at Transaction.ts:1191. Moving out of the self‑DM was never covered. The gating code in ReportPrimaryActionUtils.ts itself has not changed in ~3 months, so this is a long‑standing omission rather than a recent regression.

Note on affected platforms. Nothing in this chain is platform‑specific — there are no .native variants of the header components or useOnyx — so the Android/iOS-only marking most likely reflects Applause's test coverage rather than a platform‑gated code path. I did not run a runtime repro to confirm.

Extra symptom worth checking. The one‑sided stale violation on the second self‑DM scan (before it is submitted) should also be user‑visible per the code. Worth a look during QA.

Possibly related issues

• Expensify/App#97838 — a rate violation shows briefly after an edit. Same class of bug (violation painted from stale Onyx then cleared), different violation type.
• Expensify/App#98835 — category violation missing on a duplicated scan expense. Touches duplicate scan violations, but the opposite symptom.

Neither looks like a duplicate of this one.

---

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

---

view run · view recording

[melvin-bot]

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

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[QichenZhu]

@MelvinBot, should the two expenses be considered duplicates in this case?

[MelvinBot]

No — not once they've been submitted to two different people.

Two scans of the same receipt do match the detection criteria (amount, currency, date, plus merchant / order number / card last 4 for scanned receipts), so a flag is reasonable while both expenses sit together in the self-DM. After step 4 they live on two separate 1:1 IOU reports with different recipients, and there neither the eligibility nor the resolution holds up:

• Duplicate detection is a Collect/Control feature (help site). A 1:1 "submit to a friend" expense has no workspace, so it shouldn't carry duplicatedTransaction at all.
• Review duplicates resolves by keeping one expense and discarding the rest. Two expenses owed by two different people on two different reports can't be merged, so the button has nothing valid to do.

So the Expected Result in the issue is right, and the proposal's direction holds: the App shouldn't paint the button from a stale one-sided violation.

Supporting detail and the one check that settles it

The App has no guard for this case. The personal-policy bail-out at ReportPrimaryActionUtils.ts:503-506 only covers expense reports; a 1:1 submit creates an IOU report, so it falls straight through to isReviewDuplicatesAction. And isDuplicate is a pure function of the violation's presence — it never checks that data.duplicates still resolves to real, reviewable, same-report transactions, the way TransactionPreview/index.tsx:68 already does.

What I could not confirm. I have no access to the backend duplicate-detection code, and my runtime check of whether a personal (no-workspace) expense can carry a duplicate violation didn't complete, so this is a reading of the public criteria plus the App code — not a confirmed backend behaviour.

The check that settles it: does the ConvertTrackedExpenseToRequest response still echo duplicatedTransaction for the moved transaction? If it does, the backend intends the pair to stay flagged across recipients, and the bug flips — the button should persist, not appear-and-vanish. Even then the App needs work, because Review duplicates can't merge across two 1:1 reports.

Worth deciding either way: double-claiming one receipt to two different friends is real behaviour someone might want caught. That's a product call, not something the code answers.

---

view run · view recording

[QichenZhu]

@MelvinBot, should the two expenses be considered duplicates in this case?

No — not once they've been submitted to two different people.

@Expensify/product, could you confirm if the above is accurate? Thanks!

[trjExpensify]

It's not really about who they are submitted to, but rather, dupe detection is a business feature so if the expenses are on IOUReports they don't flag with duplicate violations.

[QichenZhu]

@MelvinBot, based on the above, do you think this is a frontend or backend issue?

[MelvinBot]

Frontend — with one backend question worth confirming separately.

trjExpensify's rule ("dupe detection is a business feature, so expenses on IOUReports don't flag") isn't encoded anywhere in the App. The personal-policy bail-out at ReportPrimaryActionUtils.ts:511-514 only covers type === 'expense', so an IOU report falls straight through to isReviewDuplicatesAction, which checks only submitter/approver + open/processing — no report-type or policy gate at all. So the App renders "Review duplicates" on a 1:1 IOU report whenever the violation key happens to hold a duplicatedTransaction.

And the App puts the stale violation there itself. Opening an expense from Spend → Expenses merges the Search snapshot's violations straight into live Onyx at Report/index.ts:1868-1877, with no successData/failureData rollback. That's the flash's first frame; the OpenReport response replaces it — second frame, button gone. That is exactly step 5 of the repro.

Fix is frontend: gate isReviewDuplicatesAction on a group policy (mirroring the existing expense-report bail-out, and also in getTransactionThreadPrimaryAction, which has no guard whatsoever), and stop writing unvalidated snapshot violations into live Onyx.

Why the timing points at the client, and the backend part I can't confirm

The convert response can't be what flashes. ConvertTrackedExpenseToRequest and OpenReport are both WRITE commands, so their payloads are concatenated and applied in a single Onyx.update in QueuedOnyxUpdates.ts:56-96 — one render, no visible flash. A flash needs two separate Onyx batches. The Search path gives exactly that: an immediate optimistic merge, then the server response later.

Supporting client-side gaps:

• isDuplicate is a pure presence check — it never resolves data.duplicates to confirm the partner transactions still exist or are reviewable.
• The convert path nulls the violation in optimisticData (TrackExpense.ts:746-750) with no successData re-assert — the guard that was deliberately added on the move-to-self-DM path for this exact symptom (Transaction.ts:1253-1257, and the comment at TransactionUtils/index.ts:2996-3005).
• removeTransactionFromDuplicateTransactionViolation is wired into delete and update but not the convert path, so the sibling scan keeps a one-sided duplicates list.
• useTransactionViolations.ts:21 discards useOnyx loading status behind an empty-array default, so "loading" and "no violations" are indistinguishable.

The backend question. The App never computes duplicatedTransaction — ViolationsUtils.ts:1012 is a translation case, and every other reference reads, filters, or dismisses it. So the violation is server-originated. Worth confirming whether the Search response still returns duplicatedTransaction for these transactions after they land on IOU reports — if it does, that's a second bug on the server side. I could not verify that from the App code, and it doesn't change the frontend fix: the App shouldn't offer an action that can't be performed (two expenses owed by two different people on two different reports can't be merged).

---

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