[Due for payment 2026-07-17] [$250] Spends - Changing the workspace rule doesn't update the row's indicator dynamically

[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: v9.4.9-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #93271
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 / Chrome, iPhone 13 / iOS 26.5, Samsung Galaxy A52 / Android 14
App Component: Search

Action Performed:

Preconditions:

• Logged in to any account that has at least one workspace (it's recommended to use a new account to prevent Concierge categorizing expense from past activities)

Steps:

1. In workspace settings, navigate to Category settings and toggle off "member must categorize all expenses"
2. Create an expense to the workspace without category
3. Navigate to Spend and observe the just created expense row (take a note that has no violation here)
4. Navigate back to workspace setting, navigate to Category settings and toggle on "member must categorize all expenses"
5. Navigate back to Spend and observe the just created expense row for several moment
6. Click the expense row and close the RHP

Expected Result:

Without opening the expense row, the expense row's indicator should updates live after changing a workspace rule

Actual Result:

Without opening the expense row, the expense row's indicator doesn't updates live after changing a workspace rule. User needs to open the expense row to make the violation updated

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7182966_1781657567131.categories_violation.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Rizky Gunawan
Bug ID: 7182966

Upwork Automation - Do Not Edit

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

Issue Owner

Current Issue Owner: @jayeshmangwani

[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/1f8e55d2b9d8d3f0cd4a76287ac087079d9ae8f9425c4e6f603098898055e933

[MelvinBot]

Proposal

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

In the Search ("Spend") view, toggling a workspace category rule ("members must categorize all expenses") does not update an existing expense row's violation (RBR) indicator live. The user has to open the expense (which fires OpenReport) before the missing-category violation appears on the row.

What is the root cause of that problem?

The Search transaction row reads its violation indicator from the live TRANSACTION_VIOLATIONS Onyx collection (it deliberately bypasses the search snapshot), at TransactionListItem/index.tsx:105.

The row does not re-derive most violations itself — it only re-syncs the attendees rule on the client via syncMissingAttendeesViolation at TransactionListItem/index.tsx:146-157 (note the in-code comment: "can be removed later when BE handles this"). There is no equivalent client-side re-derivation for the missingCategory rule.

So when requiresCategory is toggled on, the row already has the live policy value (requiresCategory: true) and the live transaction (no category), but it has no mechanism to compute the missingCategory violation from them. It depends on a fresh TRANSACTION_VIOLATIONS entry being pushed. The optimistic recompute that exists (setWorkspaceRequiresCategory → pushTransactionViolationsOnyxData) does not reliably refresh the row, so the indicator stays stale until the user opens the expense and OpenReport returns refreshed violations.

Supporting evidence

• Row's RBR source is the live collection, not the snapshot: TransactionListItem/index.tsx:105 (originalUseOnyx(TRANSACTION_VIOLATIONS...), with the comment at lines 7-9 explaining it reads real-time Onyx, not the snapshot).
• Live policy is available on the row: policyForViolations = parentPolicy ?? snapshotPolicy at index.tsx:136, where parentPolicy is read live.
• Existing per-rule client stopgap (attendees only): syncMissingAttendeesViolation at AttendeeUtils.ts:114.
• missingCategory is added by ViolationsUtils.getViolationsOnyxData when requiresCategory && !category, but that path runs in the policy-action optimistic push, not on the row.
• Opening the expense fires OpenReport, whose response merges refreshed transactionViolations — which is why the workaround (open the row) works.

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

Mirror the existing attendees pattern for the category rule:

1. Add a syncMissingCategoryViolation helper (alongside syncMissingAttendeesViolation) that, given the current violations list, re-derives whether a missingCategory violation should be present using the live policy requiresCategory flag, the live transaction category, and policyCategories — adding it when the rule is on and no (valid/required) category is set, and removing it otherwise.
2. Apply it in TransactionListItem/index.tsx immediately after the attendees sync, feeding it policyForViolations.requiresCategory, transaction?.category, and policyCategories (all already read live in that component).

Because the row already subscribes live to the policy and transaction, the indicator will update immediately when the rule toggles, with no dependency on a backend/optimistic push reaching that specific transaction. Reuse the existing missingCategory logic in ViolationsUtils rather than duplicating the rule.

What alternative solutions did you explore?

• Refresh the search snapshot on rule toggle — rejected: the row already reads live violations, not the snapshot, so this wouldn't address the RBR indicator.
• Broaden the optimistic push in setWorkspaceRequiresCategory — this could help, but it's bounded by which reports/transactions usePolicyData has loaded and is harder to make robust than a per-row re-derivation that uses data the row already has live. The attendees precedent shows the row-level sync is the established approach here.

---

Note: I could not reproduce this end-to-end in a running app, so the recommended fix is based on code analysis (confidence: medium-high). I recommend verifying with the repro steps before sizing.

---

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

[lorretheboy]

Proposal

What is the root cause of that problem?

The Spend/Search expense row only re-derives one violation type live — missingAttendees. When the workspace "members must categorize all expenses" rule (requiresCategory) flips, the row's category indicator is never recomputed.

In ExpenseReportListItem, the only render-time violation sync that runs is for attendees, even though it fetches the live policy and categories and the comment claims it makes violations "show immediately when category settings change":

App/src/components/Search/SearchList/ListItem/ExpenseReportListItem.tsx

Lines 149 to 176 in 257cd2d

	const reportForViolations = parentReport ?? snapshotReport;
	// Sync missingAttendees violation at render time for each transaction in the report
	// This ensures violations show immediately when category settings change, without needing to click the row
	const hasSyncedMissingAttendeesViolation = useMemo(() => {
	if (!isAttendeeTrackingEnabled(policyForViolations)) {
	return false;
	}
	const isInvoice = isInvoiceReport(reportItem) || reportItem.type === CONST.REPORT.TYPE.INVOICE;
	return reportItem?.transactions?.some((transaction) => {
	const relevantViolations = (transaction.violations ?? []).filter(
	(violation) =>
	!isViolationDismissed(transaction, violation, currentUserDetails.email ?? '', currentUserDetails.accountID, reportForViolations, policyForViolations) &&
	shouldShowViolation(reportForViolations, policyForViolations, violation.name, currentUserDetails.email ?? '', false, transaction),
	);
	const violations = syncMissingAttendeesViolation(
	relevantViolations,
	policyCategories,
	transaction.category ?? '',
	transaction.attendees,
	currentUserDetails,
	isAttendeeTrackingEnabled(policyForViolations),
	policyForViolations.type === CONST.POLICY.TYPE.CORPORATE,
	isInvoice,
	);
	return violations.some((violation) => violation.name === CONST.VIOLATIONS.MISSING_ATTENDEES);

The dot indicator is then driven by:

App/src/components/Search/SearchList/ListItem/ExpenseReportListItem.tsx

Line 315 in 257cd2d

styles.userSelectNone,

So hasAnyVisibleViolations = precomputed reportItem.hasVisibleViolations (from the search snapshot, which still has no missingCategory because the expense had none when listed) OR the attendees-only live sync. Nothing recomputes missingCategory from the live requiresCategory value. The live policy and categories the row already loads go unused for this case:

App/src/components/Search/SearchList/ListItem/ExpenseReportListItem.tsx

Lines 90 to 93 in 257cd2d

	const [isTrackIntentUser] = useOnyx(ONYXKEYS.NVP_INTRO_SELECTED, {selector: isTrackIntentUserSelector});
	// Fetch live policy categories from Onyx to sync violations at render time
	const [parentPolicy] = originalUseOnyx(`${ONYXKEYS.COLLECTION.POLICY}${getNonEmptyStringOnyxID(reportItem.policyID)}`);

Opening the expense calls OpenReport, which returns the backend-recomputed violations and writes them to the live TRANSACTION_VIOLATIONS collection — that's why the workaround of opening the row makes the dot appear.

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

Mirror the attendees handling for category violations in the same row. Using the already-fetched parentPolicy (requiresCategory) and policyCategories, compute a render-time hasSyncedMissingCategoryViolation per transaction and OR it into hasAnyVisibleViolations. The exact add/remove logic already exists and should be reused so both paths stay consistent:

App/src/libs/Violations/ViolationsUtils.ts

Lines 445 to 448 in 257cd2d

	// Add 'missingCategory' violation if category is required and not set
	if (!hasMissingCategoryViolation && policyRequiresCategories && !categoryKey && !isSelfDM) {
	newTransactionViolations.push({name: 'missingCategory', type: CONST.VIOLATION_TYPES.VIOLATION, showInReview: true});
	}

Concretely: factor the missingCategory/categoryOutOfPolicy decision in ViolationsUtils into a small helper (like syncMissingAttendeesViolation) and call it in the row's useMemo next to the attendees sync, keyed off policyForViolations.requiresCategory, policyCategories, and each transaction's category. This makes the dot react the moment the rule is toggled, without opening the expense.

What alternative solutions did you explore? (Optional)

Make the optimistic recompute reach Search-listed transactions. pushTransactionViolationsOnyxData only iterates transactions present in policyData.transactionsAndViolations and bails when that set is empty, so transactions surfaced only via the search snapshot get no optimistic missingCategory write:

App/src/libs/ReportUtils.ts

Lines 2032 to 2046 in 257cd2d

	const nonInvoiceReportTransactionsAndViolations = policyData.reports.reduce<ReportTransactionsAndViolations[]>((acc, report) => {
	// Skipping invoice reports since they should not have any category or tag violations
	if (isInvoiceReport(report)) {
	return acc;
	}
	const reportTransactionsAndViolations = policyData.transactionsAndViolations[report.reportID];
	if (!isEmptyObject(reportTransactionsAndViolations) && !isEmptyObject(reportTransactionsAndViolations.transactions)) {
	acc.push(reportTransactionsAndViolations);
	}
	return acc;
	}, []);
	if (nonInvoiceReportTransactionsAndViolations.length === 0) {
	return;
	}

Extending it to also cover the affected search transactions would fix it at the write layer, but the render-time sync is the lighter, more localized change and matches the pattern the row already uses for attendees.

[mukhrr]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-17 06:32:51 UTC.

Proposal

What is the root cause of that problem?

This is a Search snapshot vs live transaction-violation sync gap.

When the category rule is toggled, we do call pushTransactionViolationsOnyxData():

App/src/libs/actions/Policy/Category.ts

Lines 1239 to 1288 in 7af4b0e

	function setWorkspaceRequiresCategory(policyData: PolicyData, requiresCategory: boolean) {
	const policyID = policyData.policy?.id;
	const policyOptimisticData: Partial<Policy> = {
	requiresCategory,
	errors: {
	requiresCategory: null,
	},
	pendingFields: {
	requiresCategory: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	},
	};
	const onyxData: OnyxData<typeof ONYXKEYS.COLLECTION.POLICY> = {
	optimisticData: [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.POLICY}${policyID}`,
	value: policyOptimisticData,
	},
	],
	successData: [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.POLICY}${policyID}`,
	value: {
	errors: {
	requiresCategory: null,
	},
	pendingFields: {
	requiresCategory: null,
	},
	},
	},
	],
	failureData: [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.POLICY}${policyID}`,
	value: {
	requiresCategory: !requiresCategory,
	errors: ErrorUtils.getMicroSecondOnyxErrorWithTranslationKey('workspace.categories.updateFailureMessage'),
	pendingFields: {
	requiresCategory: null,
	},
	},
	},
	],
	};
	pushTransactionViolationsOnyxData(onyxData, policyData, policyOptimisticData);

But that optimistic recompute only reaches transactions present in policyData.transactionsAndViolations:

App/src/libs/ReportUtils.ts

Lines 2032 to 2046 in 7af4b0e

	const nonInvoiceReportTransactionsAndViolations = policyData.reports.reduce<ReportTransactionsAndViolations[]>((acc, report) => {
	// Skipping invoice reports since they should not have any category or tag violations
	if (isInvoiceReport(report)) {
	return acc;
	}
	const reportTransactionsAndViolations = policyData.transactionsAndViolations[report.reportID];
	if (!isEmptyObject(reportTransactionsAndViolations) && !isEmptyObject(reportTransactionsAndViolations.transactions)) {
	acc.push(reportTransactionsAndViolations);
	}
	return acc;
	}, []);
	if (nonInvoiceReportTransactionsAndViolations.length === 0) {
	return;
	}

policyData.transactionsAndViolations comes from useAllReportsTransactionsAndViolations(), not from the current Search snapshot:

App/src/hooks/usePolicyData/index.ts

Lines 17 to 47 in 7af4b0e

	function usePolicyData(policyID?: string): PolicyData {
	const policy = usePolicy(policyID);
	const allReportsTransactionsAndViolations = useAllReportsTransactionsAndViolations();
	// Stable selector for useOnyx to avoid defining the selector inline
	const reportsSelectorCallback = useCallback(
	(allReports: OnyxCollection<Report>) => {
	if (!policyID || !allReports || !allReportsTransactionsAndViolations) {
	return {};
	}
	// Filter reports to only include those that belong to the specified policy and have associated transactions
	return Object.keys(allReportsTransactionsAndViolations).reduce<Record<string, Report>>((acc, reportID) => {
	const policyReport = allReports[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`];
	if (policyReport?.policyID === policyID) {
	acc[reportID] = policyReport;
	}
	return acc;
	}, {});
	},
	[policyID, allReportsTransactionsAndViolations],
	);
	const [tags] = useOnyx(`${ONYXKEYS.COLLECTION.POLICY_TAGS}${policyID}`, undefined, [policyID]);
	const [categories] = useOnyx(`${ONYXKEYS.COLLECTION.POLICY_CATEGORIES}${policyID}`, undefined, [policyID]);
	const [reports] = useOnyx(ONYXKEYS.COLLECTION.REPORT, {selector: reportsSelectorCallback}, [policyID, allReportsTransactionsAndViolations]);
	const transactionsAndViolations = useMemo(() => {
	if (!reports || !allReportsTransactionsAndViolations) {
	return {};
	}
	return Object.keys(reports).reduce<ReportTransactionsAndViolationsDerivedValue>((acc, reportID) => {

So if the expense is visible in Spend from Search data, but its report transactions are not hydrated in useAllReportsTransactionsAndViolations, the rule toggle does not write a new missingCategory violation.

History supports this RCA. PR #93271 moved Search away from screen-level live violation merging:

#93271

Then this commit added a scoped live-violation selector for unhydrated report rows:

cfbe176

That fix helps when TRANSACTION_VIOLATIONS already contains the updated violation. It does not help here because the optimistic write is skipped before missingCategory is ever added.

A similar render-time sync already exists for missingAttendees:

App/src/components/Search/SearchList/ListItem/TransactionListItem/index.tsx

Lines 136 to 156 in 7af4b0e

	const onyxViolations = (transactionViolationsForRow ?? []).filter(
	(violation: TransactionViolation) =>
	!isViolationDismissed(transactionItem, violation, currentUserDetails.email ?? '', currentUserDetails.accountID, reportForViolations, policyForViolations) &&
	shouldShowViolation(reportForViolations, policyForViolations, violation.name, currentUserDetails.email ?? '', false, transactionItem),
	);
	const isInvoice = isInvoiceReport(reportForViolations) || reportForViolations.type === CONST.REPORT.TYPE.INVOICE;
	// Sync missingAttendees violation with current policy category settings (can be removed later when BE handles this)
	// Use live transaction data (attendees, category) to ensure we check against current state, not stale snapshot
	const attendeeOnyxViolations = syncMissingAttendeesViolation(
	onyxViolations,
	policyCategories,
	transaction?.category ?? transactionItem.category ?? '',
	transaction?.comment?.attendees ?? transactionItem.attendees,
	currentUserDetails,
	isAttendeeTrackingEnabled(policyForViolations),
	policyForViolations?.type === CONST.POLICY.TYPE.CORPORATE,
	isInvoice,
	);
	const transactionViolations = mergeProhibitedViolations(attendeeOnyxViolations);

The report row has an attendee-only fallback, but not a category fallback:

App/src/components/Search/SearchList/ListItem/ExpenseReportListItem.tsx

Lines 149 to 176 in 7af4b0e

	// Sync missingAttendees violation at render time for each transaction in the report
	// This ensures violations show immediately when category settings change, without needing to click the row
	const hasSyncedMissingAttendeesViolation = useMemo(() => {
	if (!isAttendeeTrackingEnabled(policyForViolations)) {
	return false;
	}
	const isInvoice = isInvoiceReport(reportItem) || reportItem.type === CONST.REPORT.TYPE.INVOICE;
	return reportItem?.transactions?.some((transaction) => {
	const relevantViolations = (transaction.violations ?? []).filter(
	(violation) =>
	!isViolationDismissed(transaction, violation, currentUserDetails.email ?? '', currentUserDetails.accountID, reportForViolations, policyForViolations) &&
	shouldShowViolation(reportForViolations, policyForViolations, violation.name, currentUserDetails.email ?? '', false, transaction),
	);
	const violations = syncMissingAttendeesViolation(
	relevantViolations,
	policyCategories,
	transaction.category ?? '',
	transaction.attendees,
	currentUserDetails,
	isAttendeeTrackingEnabled(policyForViolations),
	policyForViolations.type === CONST.POLICY.TYPE.CORPORATE,
	isInvoice,
	);
	return violations.some((violation) => violation.name === CONST.VIOLATIONS.MISSING_ATTENDEES);
	});
	}, [reportItem, policyCategories, policyForViolations, reportForViolations, currentUserDetails]);

App/src/components/Search/SearchList/ListItem/ExpenseReportListItem.tsx

Lines 310 to 315 in 7af4b0e

	// Show violation description if either:
	// 1. Pre-computed hasVisibleViolations from search data, OR
	// 2. Synced missingAttendees violation computed at render time (for stale data)
	// We're using || instead of ?? because the variables are boolean
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	const hasAnyVisibleViolations = reportItem?.hasVisibleViolations || hasSyncedMissingAttendeesViolation;

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

Add a small Search row-level derivation for missingCategory, using the existing category violation rules, but only for display. Do not write to Onyx from render.

Preview:

+ const categorySyncedViolations = syncMissingCategoryViolation(
+     attendeeOnyxViolations,
+     transaction?.category ?? transactionItem.category ?? '',
+     policyForViolations,
+     policyCategories,
+     isInvoice,
+ );
- const transactionViolations = mergeProhibitedViolations(attendeeOnyxViolations);
+ const transactionViolations = mergeProhibitedViolations(categorySyncedViolations);

For report rows, include the same derived category state in the indicator calculation:

- const hasAnyVisibleViolations = reportItem?.hasVisibleViolations || hasSyncedMissingAttendeesViolation;
+ const hasAnyVisibleViolations =
+     reportItem?.hasVisibleViolations ||
+     hasSyncedMissingAttendeesViolation ||
+     hasSyncedMissingCategoryViolation;

To avoid regressions:

• Only add/remove derived missingCategory.
• Skip invoice reports.
• Remove derived missingCategory when requiresCategory becomes false.
• Do not recompute tax/tag/receipt violations in the Search render path.
• Keep existing Onyx violations as the source of truth when available.
• Add tests for toggling requiresCategory on and off while the row is rendered from Search snapshot data.

What alternative solutions did you explore? (Optional)

Make the optimistic recompute reach Search-listed transactions. pushTransactionViolationsOnyxData only sees transactions present in policyData.transactionsAndViolations and bails when that set is empty, so transactions shown only via the Search snapshot get no optimistic missingCategory write:

App/src/libs/ReportUtils.ts

Lines 2032 to 2046 in 7af4b0e

	const nonInvoiceReportTransactionsAndViolations = policyData.reports.reduce<ReportTransactionsAndViolations[]>((acc, report) => {
	// Skipping invoice reports since they should not have any category or tag violations
	if (isInvoiceReport(report)) {
	return acc;
	}
	const reportTransactionsAndViolations = policyData.transactionsAndViolations[report.reportID];
	if (!isEmptyObject(reportTransactionsAndViolations) && !isEmptyObject(reportTransactionsAndViolations.transactions)) {
	acc.push(reportTransactionsAndViolations);
	}
	return acc;
	}, []);
	if (nonInvoiceReportTransactionsAndViolations.length === 0) {
	return;
	}

Extending it to also cover Search snapshot transactions would fix this at the write layer, but the render-time derivation is safer because it follows the existing Search live-data pattern and avoids coupling policy actions to Search cache state.

[ahmdshrif]

Proposal

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

On the Spends view, a row's violation indicator (RBR) is computed once from the search snapshot. When you change a workspace rule so that a transaction gains or loses a violation, the row's indicator does not update dynamically — you have to reload/re-run the search to see it.

What is the root cause of that problem?

PR #93271 ("Search live-merge: remove policies/violations from getSections") removed the screen-level live merge of policies and allTransactionViolations from the Search component and from getSections, so sections are now derived purely from the static snapshot:

App/src/components/Search/index.tsx

Lines 341 to 344 in 257cd2d

	const previousTransactions = usePrevious(transactions);
	const [reportActions] = useOnyx(ONYXKEYS.COLLECTION.REPORT_ACTIONS);
	const [outstandingReportsByPolicyID] = useOnyx(ONYXKEYS.DERIVED.OUTSTANDING_REPORTS_BY_POLICY_ID);
	const [policyCategories] = useOnyx(ONYXKEYS.COLLECTION.POLICY_CATEGORIES);

The intent was to recompute the badge per-row from live Onyx instead. But that live-merge was only added to ExpenseReportListItem, not to TransactionGroupListItem (the grouped Spends rows). There, both the violations and the policy used to build the indicator come exclusively from transactionsSnapshot.data, with no live useOnyx subscription:

App/src/components/Search/SearchList/ListItem/TransactionGroupListItem.tsx

Lines 497 to 526 in 257cd2d

	const snapshotData = transactionsSnapshot?.data;
	const groupViolations: Record<string, TransactionViolations | undefined> = {};
	if (snapshotData) {
	for (const [key, value] of Object.entries(snapshotData)) {
	if (key.startsWith(ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS)) {
	groupViolations[key] = value as TransactionViolations;
	}
	}
	}
	const filteredViolations: Record<string, TransactionViolation[]> = {};
	if (snapshotData) {
	for (const key of Object.keys(snapshotData)) {
	if (!key.startsWith(ONYXKEYS.COLLECTION.TRANSACTION)) {
	continue;
	}
	const snapshotTransaction = snapshotData[key as keyof typeof snapshotData] as Transaction;
	if (!snapshotTransaction || typeof snapshotTransaction !== 'object' || !('transactionID' in snapshotTransaction) || !('reportID' in snapshotTransaction)) {
	continue;
	}
	const report = snapshotData[`${ONYXKEYS.COLLECTION.REPORT}${snapshotTransaction.reportID}`];
	const policy = snapshotData[`${ONYXKEYS.COLLECTION.POLICY}${report?.policyID}`];
	if (report && policy) {
	const transactionViolations = groupViolations[`${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${snapshotTransaction.transactionID}`];
	if (transactionViolations) {
	const merged = mergeProhibitedViolations(
	transactionViolations.filter((violation) => shouldShowViolation(report, policy, violation.name, currentUserDetails?.email ?? '', true, snapshotTransaction)),
	);

Because groupViolations and policy are read from the frozen snapshot, a live rule/violation change never triggers a recompute of filteredViolations, so the indicator passed at line 588 is stale.

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

Give TransactionGroupListItem the same live merge ExpenseReportListItem received: subscribe to live transaction violations scoped to the snapshot transaction IDs (and live policy), and prefer them over the snapshot values when building filteredViolations.

const snapshotTransactionIDs = /* ids from snapshotData */;
const selector = transactionViolationsByIDsSelector(snapshotTransactionIDs);
const [liveViolations] = useOnyx(ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS, {selector}, [selector]);
// when building filteredViolations, read from liveViolations ?? groupViolations
const policy = livePolicies?.[`${ONYXKEYS.COLLECTION.POLICY}${report?.policyID}`] ?? snapshotData[`${ONYXKEYS.COLLECTION.POLICY}${report?.policyID}`];

This mirrors the existing pattern in ExpenseReportListItem (transactionViolationsByIDsSelector). Regression check: ensure the badge still renders correctly before live violations hydrate (fall back to snapshot), so rows that were never opened this session still show the snapshot indicator initially.

[melvin-bot]

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

[dilshodmackbook-sketch]

Proposal

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

In Search (Spend), an expense row's violation indicator doesn't update live after toggling the workspace "Members must categorize all expenses" rule — the user has to open the expense to make the missing-category violation appear.

What is the root cause of that problem?

PR #93271 removed the screen-level violation merge from getSections and made each Search row reflect violations from live Onyx data instead. In the transaction row, the displayed violations are built purely from what's already in the live TRANSACTION_VIOLATIONS collection for that transaction:

App/src/components/Search/SearchList/ListItem/TransactionListItem/index.tsx

Line 102 in 257cd2d

const [parentReport] = originalUseOnyx(`${ONYXKEYS.COLLECTION.REPORT}${getNonEmptyStringOnyxID(transactionItem.reportID)}`);

App/src/components/Search/SearchList/ListItem/TransactionListItem/index.tsx

Lines 136 to 156 in 257cd2d

	const policyForViolations = parentPolicy ?? snapshotPolicy;
	const reportForViolations = parentReport ?? snapshotReport;
	const onyxViolations = (transactionViolationsForRow ?? []).filter(
	(violation: TransactionViolation) =>
	!isViolationDismissed(transactionItem, violation, currentUserDetails.email ?? '', currentUserDetails.accountID, reportForViolations, policyForViolations) &&
	shouldShowViolation(reportForViolations, policyForViolations, violation.name, currentUserDetails.email ?? '', false, transactionItem),
	);
	const isInvoice = isInvoiceReport(reportForViolations) || reportForViolations.type === CONST.REPORT.TYPE.INVOICE;
	// Sync missingAttendees violation with current policy category settings (can be removed later when BE handles this)
	// Use live transaction data (attendees, category) to ensure we check against current state, not stale snapshot
	const attendeeOnyxViolations = syncMissingAttendeesViolation(
	onyxViolations,
	policyCategories,
	transaction?.category ?? transactionItem.category ?? '',
	transaction?.comment?.attendees ?? transactionItem.attendees,
	currentUserDetails,
	isAttendeeTrackingEnabled(policyForViolations),
	policyForViolations?.type === CONST.POLICY.TYPE.CORPORATE,
	isInvoice,

The row recomputes the missingAttendees violation at render time from current policy/category settings via syncMissingAttendeesViolation, but there is no equivalent render-time recompute for missingCategory/categoryOutOfPolicy. So the row can only show a category violation if one is already present in TRANSACTION_VIOLATIONS.

The only thing that writes that optimistic missingCategory violation when the rule is toggled is setWorkspaceRequiresCategory → pushTransactionViolationsOnyxData:

App/src/libs/actions/Policy/Category.ts

Line 1288 in 257cd2d

pushTransactionViolationsOnyxData(onyxData, policyData, policyOptimisticData);

and that recompute is scoped to the policy's transactions collected by usePolicyData, which only includes reports whose policyID matches the policy:

App/src/hooks/usePolicyData/index.ts

Lines 22 to 37 in 257cd2d

	const reportsSelectorCallback = useCallback(
	(allReports: OnyxCollection<Report>) => {
	if (!policyID || !allReports || !allReportsTransactionsAndViolations) {
	return {};
	}
	// Filter reports to only include those that belong to the specified policy and have associated transactions
	return Object.keys(allReportsTransactionsAndViolations).reduce<Record<string, Report>>((acc, reportID) => {
	const policyReport = allReports[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`];
	if (policyReport?.policyID === policyID) {
	acc[reportID] = policyReport;
	}
	return acc;
	}, {});
	},
	[policyID, allReportsTransactionsAndViolations],

A just-created, not-yet-submitted expense isn't on a policy-linked expense report, so it's skipped and no optimistic missingCategory is written. Combined with the row having no render-time category recompute, the indicator stays stale until the user opens the expense — which triggers a backend recompute (OpenReport) that finally writes the violation. The same dependency on the pushed violation exists for the report-group badge, which is why opening the row is the only thing that fixes it.

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

Mirror the existing missingAttendees render-time pattern for category violations, so the Search row derives missingCategory/categoryOutOfPolicy from the live policy + categories at render time (the same requiresCategory/category logic already in ViolationsUtils.getViolationsOnyxData):

App/src/libs/Violations/ViolationsUtils.ts

Lines 419 to 447 in 257cd2d

	// Calculate client-side category violations
	const policyRequiresCategories = !!policy.requiresCategory;
	if (policyRequiresCategories) {
	const hasCategoryOutOfPolicyViolation = transactionViolations.some((violation) => violation.name === 'categoryOutOfPolicy');
	const hasMissingCategoryViolation = transactionViolations.some((violation) => violation.name === 'missingCategory');
	const categoryKey = updatedTransaction.category;
	const categoryData = policyCategories?.[categoryKey ?? ''];
	// A category being created optimistically (pendingAction === 'add') is treated as valid
	// so in-situ creation doesn't trigger a "categoryOutOfPolicy" violation before the server confirms it.
	const isCategoryInPolicy = categoryKey ? !!(categoryData?.enabled || categoryData?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD) : false;
	// Add 'categoryOutOfPolicy' violation if category is not in policy
	if (!hasCategoryOutOfPolicyViolation && !isCategoryMissing(categoryKey) && !isCategoryInPolicy) {
	newTransactionViolations.push({name: 'categoryOutOfPolicy', type: CONST.VIOLATION_TYPES.VIOLATION, showInReview: true});
	}
	// Remove 'categoryOutOfPolicy' violation if category is in policy
	if (hasCategoryOutOfPolicyViolation && updatedTransaction.category && isCategoryInPolicy) {
	newTransactionViolations = reject(newTransactionViolations, {name: 'categoryOutOfPolicy'});
	}
	// Remove 'missingCategory' violation if category is valid according to policy
	if (hasMissingCategoryViolation && (isCategoryInPolicy || isSelfDM)) {
	newTransactionViolations = reject(newTransactionViolations, {name: 'missingCategory'});
	}
	// Add 'missingCategory' violation if category is required and not set
	if (!hasMissingCategoryViolation && policyRequiresCategories && !categoryKey && !isSelfDM) {
	newTransactionViolations.push({name: 'missingCategory', type: CONST.VIOLATION_TYPES.VIOLATION, showInReview: true});

Concretely, after building onyxViolations, run a category-sync step (analogous to syncMissingAttendeesViolation) using the live policyForViolations.requiresCategory, policyCategories, and the transaction's category before mergeProhibitedViolations:

const categorySyncedViolations = syncMissingCategoryViolation(
    attendeeOnyxViolations,
    policyForViolations,
    policyCategories,
    transaction?.category ?? transactionItem.category ?? '',
);
const transactionViolations = mergeProhibitedViolations(categorySyncedViolations);

We should apply the same render-time category sync in ExpenseReportListItem (which already does the attendees sync at):

App/src/components/Search/SearchList/ListItem/ExpenseReportListItem.tsx

Lines 153 to 178 in 257cd2d

	const hasSyncedMissingAttendeesViolation = useMemo(() => {
	if (!isAttendeeTrackingEnabled(policyForViolations)) {
	return false;
	}
	const isInvoice = isInvoiceReport(reportItem) || reportItem.type === CONST.REPORT.TYPE.INVOICE;
	return reportItem?.transactions?.some((transaction) => {
	const relevantViolations = (transaction.violations ?? []).filter(
	(violation) =>
	!isViolationDismissed(transaction, violation, currentUserDetails.email ?? '', currentUserDetails.accountID, reportForViolations, policyForViolations) &&
	shouldShowViolation(reportForViolations, policyForViolations, violation.name, currentUserDetails.email ?? '', false, transaction),
	);
	const violations = syncMissingAttendeesViolation(
	relevantViolations,
	policyCategories,
	transaction.category ?? '',
	transaction.attendees,
	currentUserDetails,
	isAttendeeTrackingEnabled(policyForViolations),
	policyForViolations.type === CONST.POLICY.TYPE.CORPORATE,
	isInvoice,
	);
	return violations.some((violation) => violation.name === CONST.VIOLATIONS.MISSING_ATTENDEES);
	});
	}, [reportItem, policyCategories, policyForViolations, reportForViolations, currentUserDetails]);

so the report-group badge updates too.

Alternatively, fix it at the source: broaden the optimistic recompute so setWorkspaceRequiresCategory/pushTransactionViolationsOnyxData covers all of the policy's transactions (including unreported/just-created ones), so the missingCategory violation is written to TRANSACTION_VIOLATIONS for every affected expense and the existing per-row live subscriptions pick it up. The render-time sync is preferred because it's self-correcting and matches how attendees already work; we can pick the exact approach in the PR phase.

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

Toggling "Members must categorize all expenses" on/off should update an uncategorized expense row's violation indicator in Search live (without opening the row), and the indicator should clear when a valid category is added or the rule is turned off. Cover both the transaction row and the report-group badge.

What alternative solutions did you explore? (Optional)

Re-introduce a screen-level live violation merge in getSections (what #93271 removed) — rejected because it re-fires every visible row on any change and reverses the performance win that PR intended; the per-row render-time sync keeps that benefit while closing the category gap.

[neerajbachani]

proposal