[$250] Expense - Duplicate review still shown after admin resolves employee duplicates

[jponikarchuk]

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

---

Version Number: v9.3.50-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: https://test-management.browserstack.com/projects/2219752/folder/13176704/test-cases/41236826
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11, Chrome | iPhone SE 3rd generation, iOS 26.4 | Samsung A15, Android 16
App Component: Chat Report View

Action Performed:

Preconditions:

• Admin has a workspace with: submissions enabled (default), approvals enabled (default).
• Employee has two duplicate unsubmitted expenses in the workspace.

1. Go to https://staging.new.expensify.com/
2. As the Admin, navigate to the employee workspace chat.
3. Open the expense report, select Review duplicates, then click Keep all.
4. As the Employee, navigate to the expense report containing the two duplicates.
5. Open any expense (note that the Resolve duplicate button is still displayed).

Expected Result:

After the admin resolves employee duplicates, the duplicate review should disappear from the employee side, and the employee should only see the corrected, non duplicated expenses.

Actual Result:

Even after the admin resolves employee duplicates, the employee side still shows a RBR in LHN and duplicate review, indicating the resolution is not reflected properly.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @abzokhattab

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022044008336408596126
• Upwork Job ID: 2044008336408596126
• Last Price Increase: 2026-04-14

[MelvinBot]

Proposal

What is the root cause of that problem?

The isViolationDismissed function in TransactionUtils/index.ts:1885-1929 has a one-directional check for cross-role dismissals.

When an admin clicks "Keep all", the dismissal is recorded under the admin's email in transaction.comment.dismissedViolations.duplicatedTransaction. When the employee's client evaluates whether the violation is dismissed:

1. Line 1905: Checks if the employee's own email is in the dismissal list — it is not (only the admin's email is there).
2. Line 1920: The shouldViewAsSubmitter escape hatch (!isSubmitter && isOpenExpenseReport(iouReport)) only activates for non-submitters. Since the employee IS the submitter, isSubmitter = true, so shouldViewAsSubmitter = false.

The function returns false → isDuplicate returns true → RBR and "Review Duplicates" button persist for the employee.

In short: the code lets admins see that a submitter dismissed a violation, but there is no reciprocal logic letting submitters see that an admin dismissed it.

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

Add a reciprocal check in isViolationDismissed (TransactionUtils/index.ts): when the current user is the submitter, check whether anyone else (an admin/approver) has already dismissed the violation. If the dismissedByEmails list contains any email (meaning someone with authority dismissed it), the function should return true for the submitter as well.

This mirrors the existing shouldViewAsSubmitter block but in the opposite direction — if a non-owner dismissed the duplicate violation on an open expense report, the owner/submitter should also see it as dismissed.

What alternative solutions did you explore? (Optional)

An alternative would be to modify dismissDuplicateTransactionViolation in Transaction.ts to also record the employee's email in dismissedViolations when the admin acts on their behalf. However, this would require the admin's client to know and inject the employee's email into the dismissal record, which mixes concerns. The cleaner fix is in the read path (isViolationDismissed), not the write path.

Investigation details

Data flow:

1. Admin clicks "Keep all" → calls dismissDuplicateTransactionViolation (Review.tsx:101)
2. Optimistic update records admin's email in dismissedViolations (Transaction.ts:629-643)
3. Employee's client runs isDuplicate → isViolationDismissed (TransactionUtils/index.ts:1853)
4. Employee's email not in dismissal list → function returns false
5. shouldViewAsSubmitter is false (employee IS the submitter) → no fallback check
6. isDuplicate returns true → isReviewDuplicatesAction (ReportPrimaryActionUtils.ts:329) shows RBR and button

---

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.

[melvin-bot]

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

[melvin-bot]

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

[abzokhattab]

@MelvinBot Implement the PR