Repository navigation
Spend - Expense remains on "Violations by submitter" despite solving violation. #100114
Description
Activity
While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/b576cc3f311fdc7f38e22ee5290d63766b106759b2dc33501d50ade6006d826cYou have been assigned to this deploy blocker because you recently merged this PR: #98391
@neil-marcellini @cretadn22 you have been assigned to this deploy blocker because you reviewed the offending PR: #98391
👋 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:
- Identify the pull request that introduced this issue and revert it.
- Find someone who can quickly fix the issue.
- Fix the issue yourself.
💬 A slack conversation has been started in #expensify-open-source
🔍 Investigation Summary
Classification: Frontend bug (App feature area) — but the reported behavior is the intended semantics of the filter, not a code defect
Causing PR: #98391 - "[Insights: Violations]: Expanding group & Suggested search v2" bynkdengineer(High confidence that this PR shipped the feature; Low confidence that it introduced a defect)
Related Issues: #95859 (design issue for this feature), #98204, #98244Recommendation: DEMOTE
"Violations by submitter" is built on the
has:submitted-violationfilter, which by design matches expenses that had a violation at the moment they were submitted — it is a historical/insight view, not a live to-do list. Resolving a violation after submission does not (and cannot) change the submit-time snapshot, so the row and the expense counter correctly stay put; a revert of #98391 would not change this behavior since the matching is done server-side.Assigned:
nkdengineer(PR author),neil-marcelliniandcretadn22(approving reviewers) from the highest-confidence causing PR only
Labels: No label changes made.DeployBlockerCashwas left in place — the issue is not reproducible in production (new feature), and the demotion is a product-intent call that should be confirmed by an internal engineer before the blocker is removed.DeployBlockerwas not present, so nothing was removed there.📋 Detailed Analysis
Evidence
- The whole feature is explicitly scoped to submit-time violations. The design issue for this PR, [Due for payment 2026-09-09] [Insights: Violations][R1] App - Expanding group & Suggested search #95859, describes the expanded-group work as: "Add a Violations column showing which rules each expense broke at submission time", and specifies the suggested search query as
type:expense group-by:from date:last-month has:submitted-violation view:table limit:10. - The backend filter
has:submitted-violation(added in an earlier phase of the same project, before this PR) is specified to return expenses that had a violation when they were submitted, evaluated against the submission snapshot. Filtering and group counts are computed server-side, so the App has no say in whether the row is returned. - The App's own data model documents the same semantics — the field the Violations column reads is described as a "Snapshot of transaction violations present when the report was submitted".
- Not reproducible in production only because the feature is new; there is no prior behavior that regressed.
- The App does re-fire the search when you return to the screen (see below), so "navigate to Inbox and back doesn't help" is consistent with the server legitimately still returning the expense — it is not a stale-snapshot/caching problem.
Verification
- Suggested search definition (
has:submitted-violation,group-by:from,submitted:last-month):src/libs/SearchUIUtils.ts#L1064-L1085— added by [Insights: Violations]: Expanding group & Suggested search v2 #98391. - Violations column data source, which only ever reads
SUBMITTED/SUBMITTED_AND_CLOSEDreport actions:src/libs/SearchUIUtils.ts#L5376-L5398— added by [Insights: Violations]: Expanding group & Suggested search v2 #98391. - The immutable submit-time snapshot type:
src/types/onyx/OriginalMessage.ts#L294-L298— added by [Insights: Violations]: Expanding group & Suggested search v2 #98391. - The expanded group's sub-query keeps every filter from the parent query (including
has:submitted-violation); it only swapsgroup-byfor a concretefrom:accountID:src/libs/SearchUIUtils.ts#L3441-L3450. So the expanded list is not accidentally showing unfiltered expenses. - Refresh-on-refocus for an expanded group already exists and is not part of [Insights: Violations]: Expanding group & Suggested search v2 #98391:
src/components/Search/SearchList/ListItem/TransactionGroupListItem.tsx#L226-L247. - Files changed by [Insights: Violations]: Expanding group & Suggested search v2 #98391 confirm it touches exactly this area (suggested search, expanded group, Violations column) and contains no client-side filtering of results by current violation state.
Root Cause
There is no faulty code path. The list membership and the per-submitter expense count are produced by the server for the query
has:submitted-violation, which is evaluated against the report's submission snapshot. Clearing a violation after the report was submitted leaves that snapshot untouched, so the expense continues to match and the count stays the same. The App faithfully renders what the search returns, and the Violations column deliberately reads the same immutable submit-time record.The expected result in the report ("expense should disappear once the violation is solved") describes live-violation semantics, which is a different filter than the one this insight uses.
If the product decision is that the insight should instead reflect current violations, then:
- this is not fixable in App and a revert of [Insights: Violations]: Expanding group & Suggested search v2 #98391 would not address it;
- the change belongs in the backend filter implementation, and this issue should be re-classified as a backend issue and re-scoped rather than treated as an App deploy blocker.
- The whole feature is explicitly scoped to submit-time violations. The design issue for this PR, [Due for payment 2026-09-09] [Insights: Violations][R1] App - Expanding group & Suggested search #95859, describes the expanded-group work as: "Add a Violations column showing which rules each expense broke at submission time", and specifies the suggested search query as
This is working as intended. The "Violations by submitter" view displays expenses that had violations at the time of submission, so the expense remains visible even after the violation is resolved.
Reacted by Neil MarcelliniYep haha. Expected so closing.
I do wonder if we will see regular customer confusion and might have to add some kind of explainer text, but we can figure that out once it's proven to be an issue.
Metadata
Metadata
Assignees
Type
Projects
- Status
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.66-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: #98391
Email or phone of affected tester (no customers): ibellicotest+2766@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Search
Action Performed:
Prerequisite: Account has at least one workspace with an invited member.
Prerequisite 2: Rules enabled.
Prerequisite 3: Submissions and approvals enabled.
Expected Result:
Expense should disappear from "Violations by submitter" after violation is solved.
Actual Result:
Expense remains visible on "Violations by submitter" after violation is cleared-
Workaround:
Unknown
Platforms:
Screenshots/Videos
Bug7248564_1788313280973.By_1.mp4
View all open jobs on GitHub