[$250] Report incorrectly shows a policy violation (red-dot/RBR) after a split is reverted, even though there are no actual violations remaining.

[m-natarajan]

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

---

Version Number:
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @lschurr
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Open a report and move some expenses onto it.
2. Split an expense on the report.
3. Revert the split.
4. Open the report.

Expected Result:

The report’s RBR (red-dot) indicator matches what the opened report can actually render. Once a transaction is deleted/removed (including a reverted split child), its violations should no longer keep the indicator lit.

Actual Result:

The report shows a policy-violation red-dot indicator (RBR), but when the report is opened there are no per-transaction violations to fix. A lingering violation on the reverted/removed transaction keeps the dot lit while the opened report looks clean.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022080654765149918620
• Upwork Job ID: 2080654765149918620
• Last Price Increase: 2026-07-24

Issue Owner

Current Issue Owner: @dilshodmackbook-sketch

[exfy-zapier]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[MelvinBot]

Proposal

⚠️ Confidence: Medium — the code path is clear and two independent investigations converged on it, but the issue is marked Needs Reproduction so this hasn't been confirmed against a live Onyx state capture. One part (the backend RevertSplitTransaction response) lives outside App and should be double-checked.

What is the root cause of that problem?

The report's red-dot (RBR) is driven by whether any transaction still keyed under the report's reportID has a non-null TRANSACTION_VIOLATIONS entry. That check does not filter out deleted transactions, and it looks violations up purely by transactionID — so an orphaned violation entry (one whose transaction has been removed/reverted) keeps the dot lit even though the opened report shows nothing to fix.

When a split is reverted, each child transaction is supposed to have its violations cleared. That cleanup only happens inside the per-child delete loop, via getDeleteTrackExpenseInformation (which pushes TRANSACTION_VIOLATIONS{childID} → null). But that loop has an early exit: if the child's IOU report action can't be resolved, it logs a warning and continues before getDeleteTrackExpenseInformation runs — so that child's violations are never cleared, leaving an orphan that keeps the RBR on.

Evidence (file:line)

• RBR / violation gathering has no delete filter — transactions are grouped by reportID regardless of pendingAction: src/libs/ReportUtils.ts:1120-1143, consumed by hasViolations ReportUtils.ts:9514-9529 and the LHN red-dot path getViolatingReportIDForRBRInLHN ReportUtils.ts:9408-9489.
• Violation lookup is by transactionID only, no delete check: ViolationsUtils.ts:1163-1190 and doesTransactionSupportViolations TransactionUtils/index.ts:2107-2138.
• Revert-split child-delete loop — the only place child violations are cleared: SplitTransactionUpdate.ts:1261-1337.
• The gap — early continue skips getDeleteTrackExpenseInformation: SplitTransactionUpdate.ts:1276-1279.
• Where violations are actually cleared (skipped by the continue): TrackExpense.ts:719-723.
• The snapshot cleanup for reverted children (SplitTransactionUpdate.ts:1339-1441) nulls the transaction keys but never touches TRANSACTION_VIOLATIONS, so it doesn't compensate for a skipped child.

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

1. Primary: In the revert-split loop, clear each reverted child's TRANSACTION_VIOLATIONS{childID} (SET → null) unconditionally, so it happens even when the child's report action can't be resolved and the loop continues at SplitTransactionUpdate.ts:1276. Do it in optimisticData and failureData alongside the existing delete data, rather than relying solely on getDeleteTrackExpenseInformation.
2. Defensive (belt-and-suspenders): In the RBR computation, ignore violations for transactions that are removed / pendingAction === DELETE when gathering a report's transactions, so a stray orphaned violation can't light the dot regardless of which flow left it behind.

What alternative solutions did you explore? (Optional)

Alternatives considered

• Child left as pendingAction: DELETE instead of removed: since the grouping at ReportUtils.ts:1129 doesn't filter deleted transactions, a child that lingers with DELETE (and still-present violations) would also keep the RBR lit. Fix Fix spaces #2 above covers this case too.
• Backend dependency: the App-side revert dispatches REVERT_SPLIT_TRANSACTION. If the server response doesn't return transactionViolations: null for the removed children, the orphan can reappear after sync even if the client cleans up optimistically. This should be verified in the backend command (outside the App repo) — flag to an internal engineer if the client-side fix alone doesn't fully resolve it.

---

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

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-24 14:07:01 UTC.

Proposal

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

After a split is reverted on a report, the LHN keeps showing the report's policy-violation red-dot (RBR) even though opening the report reveals no per-transaction violation to fix. The indicator stays lit because of a violation attached to the reverted/removed transaction.

What is the root cause of that problem?

Reverting a split removes the split child transaction(s) optimistically — they are marked with pendingAction: DELETE and stay in Onyx (with their reportID and their transactionViolations entry) until the server confirms and nulls them.

The LHN RBR is computed by getViolatingReportIDForRBRInLHN, which builds the report's transaction set with a plain getReportTransactions(...) and does not exclude transactions that are pending deletion:

App/src/libs/ReportUtils.ts

Line 9428 in a4b6ddf

const transactions = getReportTransactions(potentialReport.reportID);

That set is then handed to hasViolations / hasWarningTypeViolations / hasNoticeTypeViolationsForRBRInLHN, each of which just iterates the transactions and reads transactionViolations_<transactionID> — so a DELETE-pending transaction whose violation entry still exists keeps the red dot lit:

App/src/libs/ReportUtils.ts

Lines 9508 to 9523 in a4b6ddf

	function hasViolations(
	reportID: string | undefined,
	transactionViolations: OnyxCollection<TransactionViolation[]>,
	currentUserAccountIDParam: number,
	currentUserEmailParam: string,
	shouldShowInReview?: boolean,
	reportTransactions?: Transaction[],
	report?: OnyxEntry<Report>,
	reportOwnerLogin?: string,
	policy?: OnyxEntry<Policy>,
	): boolean {
	const transactions = reportTransactions ?? getReportTransactions(reportID);
	return transactions.some((transaction) =>
	hasViolation(transaction, transactionViolations, currentUserEmailParam ?? '', currentUserAccountIDParam, report, reportOwnerLogin, policy, shouldShowInReview),
	);
	}

Meanwhile the report contents (and the sibling "is this report empty" check in the very same file) do filter out DELETE-pending transactions, which is why the opened report looks clean:

App/src/libs/ReportUtils.ts

Lines 9256 to 9257 in a4b6ddf

	// Ignore transactions that are already pending deletion so we treat the report as empty once the removal is queued.
	const transactions = (reportsTransactionsParam[report.reportID] ?? []).filter((transaction) => transaction.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE);

So the LHN aggregation and the report view disagree about whether the reverted transaction still exists. The LHN counts its lingering violation; the report doesn't render it. That mismatch is the bug, and it manifests during the window a reverted split's child sits in the DELETE-pending state.

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

Make the RBR aggregation ignore transactions that are already pending deletion, exactly like the empty-report check a few lines above (ReportUtils.ts#L9256-L9257) already does. In getViolatingReportIDForRBRInLHN:

const transactions = getReportTransactions(potentialReport.reportID).filter((transaction) => transaction.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE);

Because this filtered transactions array is already passed down into ViolationsUtils.hasVisibleViolationsForUser, hasViolations, hasWarningTypeViolations, and hasNoticeTypeViolationsForRBRInLHN, the single change fixes the whole RBR path in one place and keeps the LHN consistent with what the opened report actually renders — for reverted splits and any other flow that leaves a transaction queued for deletion.

What specific scenarios should we cover in automated tests to prevent this problem from happening again?

• Unit test for getViolatingReportIDForRBRInLHN: given a policy expense chat whose only violating transaction has pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE, it returns null (no RBR); given the same transaction without the DELETE pending action, it returns the report's ID.
• Regression test for the revert-split flow: after reverting a split (child transaction marked DELETE-pending), assert the parent policy expense chat no longer resolves an RBR while the removal is still queued.

What alternative solutions did you explore? (Optional)

Clear the violation state at the source in the revert-split flow. Today the reverse branch of updateSplitTransactions restores the original transaction with only errors: null and never touches its (or the removed child's) transactionViolations:

App/src/libs/actions/IOU/SplitTransactionUpdate.ts

Lines 1683 to 1689 in a4b6ddf

	onyxData.optimisticData?.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${originalTransactionID}`,
	value: {
	errors: null,
	},
	});

We could mirror the standard delete path, which explicitly nulls TRANSACTION_VIOLATIONS_<transactionID> optimistically and restores it on failure:

App/src/libs/actions/IOU/DeleteMoneyRequest.ts

Lines 793 to 797 in a4b6ddf

	optimisticData.push({
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transactionID}`,
	value: null,
	});

I prefer the RBR-filter fix as the primary because it addresses the inconsistency generically (the LHN should never count a transaction the report treats as removed) and mirrors an existing, tested pattern in the same function, whereas the per-flow cleanup is easy to miss again in future split/revert changes.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-24 14:04:55 UTC.

Proposal

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

After splitting an expense on a report and then reverting that split, the report keeps showing a red-dot policy-violation indicator (RBR), but opening the report shows no violation to fix — the violation is attached to a split child that was removed by the revert.

What is the root cause of that problem?

The revert-split flow deletes the split children two different ways, and only one of them actually removes the child from Onyx. The leftover child stays keyed to the report forever, and the RBR aggregation counts it while the report view refuses to render it. Chain:

1. Reverting a split runs updateSplitTransactions with isReverseSplitOperation true:

   App/src/libs/actions/IOU/SplitTransactionUpdate.ts

   Lines 226 to 227 in 1fb14eb

   	const isReverseSplitOperation =
   	splitExpenses.length === 1 && originalChildTransactions.length > 0 && hasEditableSplitExpensesLeft && allChildTransactions.length === originalChildTransactions.length;

2. In a revert, the main loop processes the ORIGINAL transaction (existingTransactionID = originalTransactionID), so only the original's ID lands in processedChildTransactionIDs — every split child falls into the undeletedTransactions cleanup loop:

   App/src/libs/actions/IOU/SplitTransactionUpdate.ts

   Lines 475 to 479 in 1fb14eb

   	const existingTransactionID = isReverseSplitOperation ? originalTransactionID : splitExpense.transactionID;
   	const splitTransaction = allTransactionsList?.[`${ONYXKEYS.COLLECTION.TRANSACTION}${existingTransactionID}`];
   	if (splitTransaction) {
   	processedChildTransactionIDs.push(splitTransaction.transactionID);
   	}

3. That loop hard-deletes only ONE child — forceDeleteSplitTransactionID is the single ID left in splitExpenses — even though the code comment states the intent for all of them ("Since original transaction will be reverted and both splits will eventually be deleted, we remove the undeleted split entirely"):

   App/src/libs/actions/IOU/SplitTransactionUpdate.ts

   Lines 1281 to 1302 in 1fb14eb

   	// For a reverse split operation (i.e. deleting one transaction from a 2-split), the other split(undeleted)
   	// transaction also gets marked for deletion optimistically. This causes the undeleted split to remain visible,
   	// resulting in 3 transactions(deleted, undeleted, and original) being shown at the same time when offline.
   	// Since original transaction will be reverted and both splits will eventually be deleted, we remove
   	// the undeleted split entirely instead of marking it for deletion.
   	const forceDeleteSplitTransactionID = isReverseSplitOperation ? splitExpenses.at(0)?.transactionID : undefined;
   	const {
   	optimisticData: deleteExpenseOptimisticData,
   	failureData: deleteExpenseFailureData,
   	successData: deleteExpenseSuccessData,
   	} = getDeleteTrackExpenseInformation(
   	splitTransactionReport,
   	undeletedTransaction?.transactionID,
   	currentReportAction,
   	undefined,
   	currentUserPersonalDetails.accountID,
   	undefined,
   	undefined,
   	undefined,
   	undefined,
   	isReportArchived || undeletedTransaction?.transactionID === forceDeleteSplitTransactionID,

4. Every other child goes through getDeleteTrackExpenseInformation with shouldRemoveIOUTransaction = false, which only merges pendingAction: DELETE onto the transaction instead of removing it:

   App/src/libs/actions/IOU/TrackExpense.ts

   Lines 709 to 717 in 1fb14eb

   	if (!shouldRemoveIOUTransaction) {
   	optimisticData.push({
   	onyxMethod: Onyx.METHOD.MERGE,
   	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`,
   	value: {
   	pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
   	},
   	});
   	}

5. The success data for that path settles nothing for the transaction or its violations key (it only clears the report action's pendingAction), so the child remains in Onyx permanently, with reportID still pointing at the expense report:

   App/src/libs/actions/IOU/TrackExpense.ts

   Lines 749 to 762 in 1fb14eb

   	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.REPORT>> = [
   	{
   	onyxMethod: Onyx.METHOD.MERGE,
   	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${chatReport?.reportID}`,
   	value: {
   	[reportAction.reportActionID]: {
   	pendingAction: null,
   	errors: null,
   	},
   	},
   	},
   	];
   	// Ensure that any remaining data is removed upon successful completion, even if the server sends a report removal response.

   . Its transactionViolations_ key is nulled only optimistically (L719-L723); a server violations push that lands afterwards (RevertSplitTransaction response ordering, or a later OpenReport/reconnect gap-fill computed while the child still existed server-side) repopulates it — exactly the "lingering violation on the reverted/removed transaction" this issue describes, and why QA can't reproduce it deterministically.
6. The RBR side counts that ghost: getViolatingReportIDForRBRInLHN feeds getReportTransactions (raw grouping by transaction.reportID, no pending-delete filter) into hasViolation, which has no deleted/pending check either:

   App/src/libs/ReportUtils.ts

   Lines 9424 to 9445 in 1fb14eb

   	// If any report has a violation, then it should have a RBR
   	const potentialReports = Object.values(deprecatedReportsByPolicyID[report.policyID] ?? {}) ?? [];
   	const violatingReport = potentialReports
   	// eslint-disable-next-line rulesdir/prefer-locale-compare-from-context
   	.sort((a, b) => (a?.created ?? '').localeCompare(b?.created ?? ''))
   	.find((potentialReport) => {
   	if (!potentialReport) {
   	return false;
   	}
   	const policy = allPolicies?.[`${ONYXKEYS.COLLECTION.POLICY}${potentialReport.policyID}`];
   	const transactions = getReportTransactions(potentialReport.reportID);
   	// Allow both open and processing reports to show RBR for violations
   	if (!isOpenOrProcessingReport(potentialReport)) {
   	return false;
   	}
   	const excludedNoticeNamesForLHN = isProcessingReport(potentialReport) ? [CONST.VIOLATIONS.MODIFIED_AMOUNT] : [];
   	return (
   	!isInvoiceReport(potentialReport) &&
   	ViolationsUtils.hasVisibleViolationsForUser(

   and

   App/src/libs/TransactionUtils/index.ts

   Lines 2117 to 2137 in 1fb14eb

   	function hasViolation(
   	transaction: Transaction | undefined,
   	transactionViolations: TransactionViolation[] | OnyxCollection<TransactionViolation[]>,
   	currentUserEmail: string,
   	currentUserAccountID: number,
   	iouReport: OnyxEntry<Report>,
   	iouReportOwnerLogin: string | undefined,
   	policy: OnyxEntry<Policy>,
   	showInReview?: boolean,
   	): boolean {
   	if (!doesTransactionSupportViolations(transaction)) {
   	return false;
   	}
   	const violations = Array.isArray(transactionViolations) ? transactionViolations : transactionViolations?.[ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS + transaction.transactionID];
   	return !!violations?.some(
   	(violation) =>
   	violation.type === CONST.VIOLATION_TYPES.VIOLATION &&
   	(showInReview === undefined || showInReview === (violation.showInReview ?? false)) &&
   	!isViolationDismissed(transaction, violation, currentUserEmail, currentUserAccountID, iouReport, iouReportOwnerLogin, policy),
   	);

7. The opened report filters out exactly these rows (!isTransactionPendingDelete(t)), so the user sees a clean report under a lit dot:

   App/src/components/MoneyRequestReportView/MoneyRequestReportTransactionList.tsx

   Line 305 in 1fb14eb

   const transactionsWithoutPendingDelete = useMemo(() => transactions.filter((t) => !isTransactionPendingDelete(t)), [transactions]);

The structural cause: the revert treats "the kept split" and "the other splits" asymmetrically, leaving unsettled pending-delete children that the RBR aggregation and the report view interpret differently. This lights every RBR surface reading the same derived value — LHN expense-chat row, report preview, and the Reports table (reportAttributes → generateReportAttributes,

App/src/libs/ReportUtils.ts

Line 13154 in 1fb14eb

const hasViolationsToDisplayInLHN = !!getViolatingReportIDForRBRInLHN(report, transactionViolations);

).

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

Make the revert force-remove EVERY child, not just the one left in splitExpenses — the treatment the kept child already receives, and the intent the existing comment already states. In SplitTransactionUpdate.ts:

// L1302: hard-delete all children during a revert, not only forceDeleteSplitTransactionID
isReportArchived || isReverseSplitOperation,
// L1321: remove each child's IOU action for the same set
if (undeletedTransaction?.transactionID && isReverseSplitOperation) {

With the transaction SET to null, a stray late violations push becomes an orphan key that getReportTransactions can no longer map to the report, so RBR stays off. Regression safety in one sentence: forward-split edits never enter this branch (isReverseSplitOperation requires exactly one remaining split), archived reports already take the forced path, and the existing failureData restores both the transaction and its report action if the API fails (TrackExpense.ts#L770-L776, SplitTransactionUpdate.ts#L1327-L1335). Secondary (optional hardening): add successData entries nulling transaction_<childID> and transactionViolations_<childID> so nothing embedded in the API response can resurrect them.

Why the obvious spot-fix does NOT work: re-nulling the transactionViolations_ key in successData doesn't fix this, because the child transaction itself remains in Onyx keyed to the report (successData carries no settle for it — TrackExpense.ts#L749), so the next server push of violations for that transactionID re-lights the dot through the unguarded getReportTransactions + hasViolation pair; the tx+violations pairing must be broken at the transaction, not the violations key.

What alternative solutions did you explore? (Optional)

1. Reader-side guard: filter !isTransactionPendingDelete(t) in getViolatingReportIDForRBRInLHN (ReportUtils.ts#L9434) / hasViolations so the dot definitionally matches what the report renders. Defensive and broad, but it edits the global RBR path for every report and masks the leftover state instead of removing it (the ghost still pollutes totals/search); acceptable as a follow-up, not the fix.
2. Only clearing violations in successData — incomplete: misses the leftover transaction (see proof above).
3. Backend note (one line): RevertSplitTransaction should also clear the deleted children's violations server-side, but the App must still remove its own optimistic leftovers, which is the mergeable fix here.

[lorretheboy]

Proposal

What is the root cause of that problem?

The red dot for a report row comes from the cached REPORT_ATTRIBUTES derived value, and its incremental recompute cannot tell which report a deleted transaction belonged to — so that report's stale brickRoadStatus: error is never refreshed.

Reverting a split deletes the split children and clears their violations by SET-ing both keys to null:

App/src/libs/actions/IOU/TrackExpense.ts

Lines 702 to 723 in 1894c8c

	if (shouldDeleteTransactionFromOnyx && shouldRemoveIOUTransaction) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`,
	value: null,
	});
	}
	if (!shouldRemoveIOUTransaction) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`,
	value: {
	pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
	},
	});
	}
	optimisticData.push({
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transactionID}`,
	value: null,
	});

When those deletions reach the reportAttributes compute, the affected report is resolved by reading transaction?.reportID from the update value — which is null for a deleted transaction — and the violations update is mapped through the transactions collection, where the transaction no longer exists, so it's filtered out:

App/src/libs/actions/OnyxDerived/configs/reportAttributes.ts

Lines 380 to 415 in 1894c8c

	if (!!transactionsUpdates || !!transactionViolationsUpdates) {
	let transactionReportIDs: string[] = [];
	if (transactionsUpdates) {
	transactionReportIDs = Object.values(transactionsUpdates).map((transaction) => `${ONYXKEYS.COLLECTION.REPORT}${transaction?.reportID}`);
	const updatedTransactionIDs = new Set(Object.keys(transactionsUpdates).map((key) => key.replace(ONYXKEYS.COLLECTION.TRANSACTION, '')));
	if (updatedTransactionIDs.size > 0) {
	for (const report of Object.values(reports)) {
	if (!report?.reportID || !report.parentReportID || !report.parentReportActionID) {
	continue;
	}
	const parentReportAction = reportActions?.[`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${report.parentReportID}`]?.[report.parentReportActionID];
	const linkedTransactionID = getLinkedTransactionID(parentReportAction);
	if (linkedTransactionID && updatedTransactionIDs.has(linkedTransactionID)) {
	transactionReportIDs.push(`${ONYXKEYS.COLLECTION.REPORT}${report.reportID}`);
	}
	}
	}
	}
	// Also handle transaction violations updates by extracting transaction IDs and finding their reports
	if (transactionViolationsUpdates) {
	const violationTransactionIDs = Object.keys(transactionViolationsUpdates).map((key) => key.replace(ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS, ''));
	const violationReportIDs = violationTransactionIDs
	.map((transactionID) => transactions?.[`${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`]?.reportID)
	.filter(Boolean)
	.map((reportID) => `${ONYXKEYS.COLLECTION.REPORT}${reportID}`);
	// Also include chat reports for expense reports that have violations
	const chatReportIDs = violationReportIDs
	.map((reportKey) => reports?.[reportKey]?.chatReportID)
	.filter(Boolean)
	.map((chatReportID) => `${ONYXKEYS.COLLECTION.REPORT}${chatReportID}`);
	transactionReportIDs = [...transactionReportIDs, ...violationReportIDs, ...chatReportIDs];
	}

Causal chain: split child is deleted + its violations cleared → neither update can be mapped back to the expense report → the report is never added to dataToIterate → the attributes computed earlier (while the child still had a violation) stay cached with brickRoadStatus: error → the red dot stays lit, while the opened report renders from live data and shows nothing to fix. Whether it reproduces depends on whether an unrelated update to the same report happens to land in the same recompute pass, which is why it's flaky.

Note the sibling derived value already solves exactly this with a persistent transaction→report map (transactionReportIDMapping) used to clean up when a transaction disappears or moves:

App/src/libs/actions/OnyxDerived/configs/reportTransactionsAndViolations.ts

Lines 62 to 71 in 1894c8c

	const previousReportID = transactionReportIDMapping[transactionKey];
	if (previousReportID && previousReportID !== reportID && reportTransactionsAndViolations[previousReportID]) {
	ensureCloned(previousReportID);
	delete reportTransactionsAndViolations[previousReportID].transactions[transactionKey];
	const transactionID = transactionKey.replace(ONYXKEYS.COLLECTION.TRANSACTION, '');
	if (transactionID) {
	delete reportTransactionsAndViolations[previousReportID].violations[`${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transactionID}`];
	}
	}

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

Fix it in the reportAttributes compute — the single convergence point for RBR — so every transaction-deletion flow (revert split, delete expense, merge) benefits:

• Maintain a module-level transactionID → reportID map, updated each pass while transactions exist (the same pattern as transactionReportIDMapping in reportTransactionsAndViolations.ts).
• When a transaction update's value is null (deleted), or a violations update points at a transaction that's no longer in the collection, fall back to that map to resolve the owning report and enqueue it (its chat report is already handled by the existing chatReportID propagation just below).

Pseudo-code for the mapping step:

transactionReportIDs = Object.entries(transactionsUpdates).map(
    ([key, transaction]) => `${ONYXKEYS.COLLECTION.REPORT}${transaction?.reportID ?? transactionIDToReportID[key]}`,
);
// violations path: transactions?.[key]?.reportID ?? transactionIDToReportID[transactionKey]

This makes the report recompute with the now-clean data, clearing the red dot as soon as the reverted split's transaction/violations are removed.

What alternative solutions did you explore? (Optional)

Adding ONYXKEYS.DERIVED.REPORT_TRANSACTIONS_AND_VIOLATIONS as a dependency of reportAttributes and using its already-maintained per-report buckets to find reports whose transactions/violations changed. It reuses the existing mapping instead of duplicating it, but chaining derived values adds an extra recompute hop, so the small local map is simpler.

[mukhrr]

Proposal

What is the root cause of that problem?

The report screen and the LHN RBR compute "the report's transactions" from two different sets.

The opened report filters out transactions whose pendingAction is delete while online, so a reverted split child is not rendered:

App/src/hooks/useReportWithTransactionsAndViolations.ts

Lines 25 to 28 in d0da049

	const filteredTransactions = useMemo(
	() => Object.values(transactions).filter((transaction) => isOffline || transaction?.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE),
	[transactions, isOffline],
	);

However, getViolatingReportIDForRBRInLHN() (used by the reportAttributes derived value, SidebarUtils, and OptionsListUtils to light the LHN red dot) passes the report's raw transaction list to every violation check:

App/src/libs/ReportUtils.ts

Lines 9427 to 9453 in d0da049

	const potentialReports = Object.values(deprecatedReportsByPolicyID[report.policyID] ?? {}) ?? [];
	const violatingReport = potentialReports
	// eslint-disable-next-line rulesdir/prefer-locale-compare-from-context
	.sort((a, b) => (a?.created ?? '').localeCompare(b?.created ?? ''))
	.find((potentialReport) => {
	if (!potentialReport) {
	return false;
	}
	const policy = allPolicies?.[`${ONYXKEYS.COLLECTION.POLICY}${potentialReport.policyID}`];
	const transactions = getReportTransactions(potentialReport.reportID);
	// Allow both open and processing reports to show RBR for violations
	if (!isOpenOrProcessingReport(potentialReport)) {
	return false;
	}
	const excludedNoticeNamesForLHN = isProcessingReport(potentialReport) ? [CONST.VIOLATIONS.MODIFIED_AMOUNT] : [];
	return (
	!isInvoiceReport(potentialReport) &&
	ViolationsUtils.hasVisibleViolationsForUser(
	potentialReport,
	transactionViolations,
	currentUserLogin,
	deprecatedCurrentUserAccountID ?? CONST.DEFAULT_NUMBER_ID,
	policy,
	transactions,

That list comes from a mapping that groups every transaction in Onyx by reportID with no pendingAction filtering:

App/src/libs/ReportUtils.ts

Lines 1120 to 1143 in d0da049

	let deprecatedReportsTransactions: Record<string, Transaction[]> = {};
	Onyx.connect({
	key: ONYXKEYS.COLLECTION.TRANSACTION,
	callback: (value) => {
	if (!value) {
	return;
	}
	deprecatedAllTransactions = Object.fromEntries(Object.entries(value).filter(([, transaction]) => transaction));
	deprecatedReportsTransactions = Object.values(value).reduce<Record<string, Transaction[]>>((all, transaction) => {
	const reportsMap = all;
	if (!transaction?.reportID) {
	return reportsMap;
	}
	if (!reportsMap[transaction.reportID]) {
	reportsMap[transaction.reportID] = [];
	}
	reportsMap[transaction.reportID].push(transaction);
	return all;
	}, {});
	},
	});

A reverse split produces exactly this state: the flow force-removes one split child but marks the other with pendingAction: delete (via getDeleteTrackExpenseInformation with shouldRemoveIOUTransaction = false), leaving it in Onyx until the API round-trip completes:

App/src/libs/actions/IOU/SplitTransactionUpdate.ts

Lines 1281 to 1303 in d0da049

	// For a reverse split operation (i.e. deleting one transaction from a 2-split), the other split(undeleted)
	// transaction also gets marked for deletion optimistically. This causes the undeleted split to remain visible,
	// resulting in 3 transactions(deleted, undeleted, and original) being shown at the same time when offline.
	// Since original transaction will be reverted and both splits will eventually be deleted, we remove
	// the undeleted split entirely instead of marking it for deletion.
	const forceDeleteSplitTransactionID = isReverseSplitOperation ? splitExpenses.at(0)?.transactionID : undefined;
	const {
	optimisticData: deleteExpenseOptimisticData,
	failureData: deleteExpenseFailureData,
	successData: deleteExpenseSuccessData,
	} = getDeleteTrackExpenseInformation(
	splitTransactionReport,
	undeletedTransaction?.transactionID,
	currentReportAction,
	undefined,
	currentUserPersonalDetails.accountID,
	undefined,
	undefined,
	undefined,
	undefined,
	isReportArchived || undeletedTransaction?.transactionID === forceDeleteSplitTransactionID,
	);

The delete helper does clear that child's violations optimistically:

App/src/libs/actions/IOU/TrackExpense.ts

Lines 708 to 722 in d0da049

	if (!shouldRemoveIOUTransaction) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`,
	value: {
	pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
	},
	});
	}
	optimisticData.push({
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transactionID}`,
	value: null,
	});

But nothing guards the violations key afterwards: any later server update (violation recompute, reconnect, search snapshot) can re-merge violations for the child while it still sits in Onyx as pending-delete. When that happens, the RBR path counts the hidden transaction's violations and lights the red dot, while the opened report renders clean — matching the report from the logs. Because this depends on server timing, it reproduces only intermittently, which is consistent with QA's "Unable to reproduce". I verified the mismatch mechanically with a unit test against the unmodified code: a report whose only violating transaction is pending deletion still returns a violating reportID from getViolatingReportIDForRBRInLHN().

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

Filter pending-deletion transactions inside getViolatingReportIDForRBRInLHN() before they reach hasVisibleViolationsForUser(), hasViolations(), hasWarningTypeViolations(), and hasNoticeTypeViolationsForRBRInLHN():

-            const transactions = getReportTransactions(potentialReport.reportID);
+            // Pending-delete transactions (e.g. a reverted split child) are not rendered on the opened report, so they must not light the RBR either
+            const transactions = getReportTransactions(potentialReport.reportID).filter((transaction) => transaction.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE);

This is the smallest complete fix: all four RBR checks then operate on the same visible transaction set as the opened report, and the single change covers every caller (the reportAttributes derived value, SidebarUtils.getReasonAndReportActionThatHasRedBrickRoad, SidebarUtils.getOptionData, and OptionsListUtils). Filtering unconditionally (rather than online-only like the hook) is safe because every delete flow clears the transaction's violations optimistically, so a pending-delete transaction can only ever contribute stale, re-merged violations.

I also added a unit test to the existing getViolatingReportIDForRBRInLHN describe block in tests/unit/ReportUtilsTest.ts: an open expense report whose only transaction has a missingCategory violation and pendingAction: delete must return null. It fails on the current code (returns the expense reportID) and passes with the fix, alongside the existing positive test that keeps legitimate violations lighting the dot.

What alternative solutions did you explore? (Optional)

I considered clearing violations again in the reverse-split action, but the delete helper already does that optimistically; the stale violation arrives from a later server update, so re-clearing at revert time cannot prevent it. I also considered filtering in each caller instead of inside the function, but that duplicates the rule and leaves future callers exposed.

While verifying, I also noticed a related hardening opportunity (out of scope here): the reportAttributes incremental recompute maps a deleted transaction update (value null) to report_undefined because the transaction no longer has a reportID, so a report can miss a recompute when its transaction is removed in an isolated update. The scoped filter above fixes the reported symptom independently of that.

[melvin-bot]

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

[wildan-m]

Proposal

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

After a split expense is reverted, the report keeps showing the red-dot (RBR) policy-violation indicator, but opening the report shows nothing to fix — the expense that carried the violation is no longer rendered anywhere in the report.

What is the root cause of that problem?

The red dot and the report body read two different transaction lists, and only the report body excludes expenses that are pending deletion.

When a split is reverted, updateSplitTransactions deletes the split children through getDeleteTrackExpenseInformation, but it only asks for the transaction to actually be removed from Onyx for one of them — splitExpenses.at(0)?.transactionID (or when the report is archived). Every other split child is passed shouldRemoveIOUTransaction: false:

App/src/libs/actions/IOU/SplitTransactionUpdate.ts

Lines 1286 to 1303 in 04e1c66

	const forceDeleteSplitTransactionID = isReverseSplitOperation ? splitExpenses.at(0)?.transactionID : undefined;
	const {
	optimisticData: deleteExpenseOptimisticData,
	failureData: deleteExpenseFailureData,
	successData: deleteExpenseSuccessData,
	} = getDeleteTrackExpenseInformation(
	splitTransactionReport,
	undeletedTransaction?.transactionID,
	currentReportAction,
	undefined,
	currentUserPersonalDetails.accountID,
	undefined,
	undefined,
	undefined,
	undefined,
	isReportArchived || undeletedTransaction?.transactionID === forceDeleteSplitTransactionID,
	);

For those, getDeleteTrackExpenseInformation does not set the transaction key to null; it only merges pendingAction: DELETE onto it, and its successData never removes it afterwards. So the reverted split child stays in Onyx indefinitely, still carrying the expense report's reportID:

App/src/libs/actions/IOU/TrackExpense.ts

Lines 702 to 717 in 04e1c66

	if (shouldDeleteTransactionFromOnyx && shouldRemoveIOUTransaction) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`,
	value: null,
	});
	}
	if (!shouldRemoveIOUTransaction) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`,
	value: {
	pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
	},
	});
	}

The report body never renders that leftover row, because MoneyRequestReportView explicitly filters out transactions whose pendingAction is DELETE before rendering:

App/src/components/MoneyRequestReportView/MoneyRequestReportView.tsx

Lines 141 to 152 in 04e1c66

	const visibleTransactions = useMemo(() => {
	if (isOffline) {
	return transactions;
	}
	// When there are no pending delete transactions, which is most of the time, we can return the same transactions keeping the same reference avoiding extra work
	const hasPendingDelete = transactions.some((transaction) => transaction.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE);
	if (!hasPendingDelete) {
	return transactions;
	}
	return transactions.filter((transaction) => transaction.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE);

The RBR does not apply that filter. getViolatingReportIDForRBRInLHN — which is the single funnel for the report's violation red dot, since generateReportAttributes derives hasAnyViolations from it — builds its transaction list straight from getReportTransactions(potentialReport.reportID):

App/src/libs/ReportUtils.ts

Line 9428 in 04e1c66

const transactions = getReportTransactions(potentialReport.reportID);

getReportTransactions returns every transaction mapped to that report regardless of pendingAction, with no deletion filtering at all:

App/src/libs/ReportUtils.ts

Lines 1271 to 1277 in 04e1c66

	function getReportTransactions(reportID: string | undefined, allReportsTransactions: Record<string, Transaction[]> = deprecatedReportsTransactions): Transaction[] {
	if (!reportID) {
	return [];
	}
	return allReportsTransactions[reportID] ?? [];
	}

That unfiltered list is then handed to all four violation checks — hasVisibleViolationsForUser, hasViolations, hasWarningTypeViolations and hasNoticeTypeViolationsForRBRInLHN:

App/src/libs/ReportUtils.ts

Lines 9437 to 9479 in 04e1c66

	return (
	!isInvoiceReport(potentialReport) &&
	ViolationsUtils.hasVisibleViolationsForUser(
	potentialReport,
	transactionViolations,
	currentUserLogin,
	deprecatedCurrentUserAccountID ?? CONST.DEFAULT_NUMBER_ID,
	policy,
	transactions,
	) &&
	(hasViolations(
	potentialReport.reportID,
	transactionViolations,
	deprecatedCurrentUserAccountID ?? CONST.DEFAULT_NUMBER_ID,
	currentUserLogin,
	true,
	transactions,
	potentialReport,
	// This path only runs for reports the current user submitted, so the report owner is the current user.
	currentUserLogin,
	policy,
	) ||
	hasWarningTypeViolations(
	potentialReport.reportID,
	transactionViolations,
	deprecatedCurrentUserAccountID ?? CONST.DEFAULT_NUMBER_ID,
	currentUserLogin,
	true,
	transactions,
	potentialReport,
	// This path only runs for reports the current user submitted, so the report owner is the current user.
	currentUserLogin,
	policy,
	) ||
	hasNoticeTypeViolationsForRBRInLHN(
	transactionViolations,
	deprecatedCurrentUserAccountID ?? CONST.DEFAULT_NUMBER_ID,
	currentUserLogin,
	transactions,
	potentialReport,
	policy,
	excludedNoticeNamesForLHN,
	))

So any violation still attached to the removed split child is counted as a live, fixable violation for the report and keeps the dot lit, while the report the user opens has already filtered that expense out — there is literally nothing on screen to act on. The indicator is being computed over expenses the report can never render.

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

Make the RBR read the same set of expenses the report actually renders, by excluding expenses that are pending deletion from the violation evaluation.

In getViolatingReportIDForRBRInLHN, after fetching the report's transactions with getReportTransactions, filter out any transaction whose pendingAction is the delete pending action before passing the list into the violation checks. This is the same exclusion MoneyRequestReportView applies when it builds its visible transactions online — offline it deliberately keeps the pending row visible until the request is sent, which is a display concern and not a reason to keep an unresolvable red dot lit. Because generateReportAttributes derives the report's hasAnyViolations from this one function, filtering here fixes the red dot everywhere it is shown for the report — the LHN row, the report list and the report header — without touching any other consumer of getReportTransactions (totals, counts, search) that legitimately needs the full list.

The result: once the reverted split child is marked for deletion it stops contributing to the report's violation state, so the dot clears at the same moment the expense disappears from the report, and a report with no renderable violations no longer shows an RBR the user cannot resolve. Violations on expenses that are genuinely still in the report are unaffected, and if the delete request fails, the existing failure data clears pendingAction again, which restores the transaction to the evaluated set and re-lights the dot correctly.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/96967-rbr-pending-delete-transactions?expand=1

What alternative solutions did you explore? (Optional)

I looked at fixing this on the write side instead — making the reverted split remove the child transactions from Onyx entirely rather than leaving them marked for deletion, i.e. passing the force-delete flag for every child in the reverse-split branch rather than only for the first one. I did not go with it because that flag was deliberately narrowed to a single child so the remaining split stays visible while the request is in flight offline, and widening it would regress that offline behaviour. It also only addresses this one flow, whereas any other path that leaves an expense in the pending-delete state would reproduce the same mismatch; filtering on the read side fixes the class of problem rather than one instance of it.

I also considered clearing the violations for the removed child at revert time. That is already done optimistically, so it does not cover a violation that comes back from the server response or from the delete's failure data, and it leaves the underlying inconsistency — the dot being computed over expenses the report will not render — in place.