[Due for payment 2026-08-19] Spend - Expense is not removed after resolving violation

[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: 9.4.52-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #97067
Email or phone of affected tester (no customers): sdsiodjnosdjiodsj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Search

Action Performed:

Precondition:

• Enable Rules.
• Invite user B to the workspace.
• User B submits an expense without category in the invited workspace.
• Perform the steps below as owner:

1. Go to staging.new.expensify.com
2. Go to Spend > Violations by submitter.
3. Click Submitted and change it to This month.
4. Expand the group.
5. Click on the expense.
6. Click Category and add a category.
7. Close the report.

Expected Result:

The expense should be removed because it no longer has violation.

Actual Result:

The expense remains when it no longer has violation.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7230490_1786395997412.9.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @cretadn22

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

[melvin-bot]

@neil-marcellini recently merged #97067, but they are OOO right now, so I'll auto-assign someone else.

[melvin-bot]

Triggered auto assignment to @grgia (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

@neil-marcellini @cretadn22 you have been assigned to this deploy blocker because you reviewed the offending PR: #97067

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Deploy Blocker Analysis

Causing PR: Expensify/App#97067 — "[Insights: Violations]: Expanding group & Suggested search" (author nkdengineer, approver cretadn22). Confirmed with High confidence — it introduced the entire "Violations by submitter" view exercised by these repro steps and is on the current staging deploy.

Root Cause: The Violations-by-submitter list membership is driven by the Search snapshot (SNAPSHOT_<hash> in Onyx), not by live violation data. Adding a category resolves the violation by updating the live transaction / transactionViolations Onyx keys, but nothing removes the row from the snapshot and no re-search is triggered — so the expense lingers until the search is re-run.

Recommended Fix: Roll forward with a targeted fix rather than revert (a revert would tear out the whole multi-file feature for a self-contained refresh gap). Hook the violation-resolution path into the existing snapshot-removal mechanism so a resolved item drops out of the list.

Investigation details & evidence

Data flow (permalinks at HEAD 4fa104b):

1. List membership comes from the snapshot. Violations are read from classifyAndPreprocess(data) where data is the snapshot — SearchUIUtils.ts:2995 — and each report group item stores hasVisibleViolations computed from that snapshot at SearchUIUtils.ts:3067-3117 via hasVisibleViolations (L2112-2162).

2. The row recomputes live violation state, but only for the badge — not membership. liveHasVisibleViolations at ExpenseReportListItem.tsx:220-234 is consumed only for the violation description/badge at ExpenseReportListItem.tsx:398-428. So after resolving the violation the badge can disappear, but the row stays.

3. An existing mechanism already handles snapshot removal — but the category-edit path doesn't use it. getSearchActionOnyxData optimistically sets SNAPSHOT_<hash>.data.report_<reportID> = null when the current search key is in snapshotRemovalKeys: Search.ts:457-480. This is wired for pay/approve/submit but not for violation resolution, so nothing evicts the expense from the VIOLATIONS_BY_SUBMITTER snapshot.

Fix options:

• Option A (preferred, matches existing pattern): when a listed item's live violations become empty for a VIOLATIONS_BY_SUBMITTER search, drop it from the snapshot the same way getSearchActionOnyxData / snapshotRemovalKeys already does for pay/approve.
• Option B: build list membership from live transactionViolations (already computed in the row) instead of the snapshot's precomputed hasVisibleViolations, so resolved items filter out on the next render.

Alternative — demote: Since this is a new feature not in production and results self-correct on re-running the search, demoting off the deploy blocker and fixing as a normal follow-up is defensible (it doesn't touch auth/payments/data-loss). I lean roll-forward because auto-removal is a core expectation of a "Violations" worklist.

Note: the checked-out App repo is a shallow clone, so git blame collapses to the boundary commit; PR attribution was confirmed via the #97067 file list, which matches the affected code exactly.

---

Next Steps: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.