[Due for payment 2026-06-02] [$250] Distance - After deleting a distance rate, the error appears only when opening the expense

[lanitochka17]

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

---

Version Number: v9.3.74-6
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-29869/folder/13176744/41237167/1417454241?sort=%2Bidentifier
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Mac 15.4.1 Safari, iPhone 13 iOS 26.3.1
App Component: Workspace Settings

Action Performed:

Preconditions: Distance rates are enabled in More features and at leas one custom created distance rate is created

1. Go to https://staging.new.expensify.com
2. Go to the workspace chat
3. Create a map distance request with a custom created distance rate (not the default distance rate)
4. Navigate to the workspace settings and delete the distance rate that was selected when creating the above expense
5. Go to Inbox

Expected Result:

After deleting the distance rate that was used to create the expense, an RBR should be displayed in the workspace chat, and the ‘Rate not valid for this workspace’ error should be displayed on the expense preview.

Actual Result:

After deleting a distance rate, the RBR in the workspace chat and the error on the expense preview appear only after opening the expense details.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7155269_1778864496571.Recording__2166.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022055342791491995210
• Upwork Job ID: 2055342791491995210
• Last Price Increase: 2026-05-15
• Automatic offers:
• FitseTLT | Contributor | 111462089

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

What is the root cause of that problem?

There are two bugs working together to cause this:

Bug 1 — return instead of continue in the violation loop (DistanceRate.ts:449-451):
In deletePolicyDistanceRates(), the for loop that adds CUSTOM_UNIT_OUT_OF_POLICY violations to affected transactions uses return instead of continue. If any transaction already has the violation, the entire function exits — skipping all remaining transactions AND the API.write() call. This means no optimistic data is applied and no server request is made.

Bug 2 — Derived system can't map violations to reports when transactions aren't loaded (reportAttributes.ts:216-218):
Even when optimistic violations are correctly written, the reportAttributes derived value maps violation updates to reports by looking up transactions?.[transactionKey]?.reportID. If the transaction object isn't loaded in the Onyx TRANSACTION collection (because the user hasn't opened the expense detail yet), this lookup returns undefined, the report is never scheduled for recomputation, and the LHN RBR never appears. Opening the expense loads the transaction into Onyx, which allows the mapping to succeed on subsequent updates.

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

Fix 1: In DistanceRate.ts:450, change return to continue so the loop skips transactions that already have the violation instead of aborting the entire function.

Fix 2: In reportAttributes.ts:216-218, when the transaction isn't in the TRANSACTION collection (so reportID is undefined), fall back to looking up the transaction's report from the TRANSACTION_VIOLATIONS data or from a broader search of report actions. Alternatively, deletePolicyDistanceRates() could include the affected report IDs in its optimistic data (e.g., by touching the report's lastVisibleActionCreated or by including an optimistic report update that triggers recomputation).

The simplest combined fix: change return → continue in DistanceRate.ts, and in the optimistic data of deletePolicyDistanceRates(), add the affected expense report keys to the optimistic update so the derived system recomputes them directly — bypassing the transaction lookup entirely.

What alternative solutions did you explore?

• Force-loading all affected transactions into Onyx before the delete — rejected because it adds unnecessary API calls and latency.
• Adding a full Onyx subscription to TRANSACTION collection in the derived config — rejected because it would cause excessive recomputation across the app.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The expense's customUnitOutOfPolicy violation (the one that renders as "Rate not valid for this workspace") is set lazily — only when the user opens the expense detail page — not eagerly when the distance rate is actually deleted. So at the moment between "admin deletes rate" and "user opens the expense," the LHN, the workspace chat preview, and the expense preview all read the stale, pre-delete value of transactionViolations_<transactionID> from Onyx, see no violation, and render no RBR or inline error. Opening the expense triggers Report.openReport(reportID), which pulls fresh data from the server including a recomputed violations list — that's the call that finally writes the violation into Onyx and makes the RBR appear everywhere else.

Concretely, here's what happens during the repro and why each surface shows what it shows:

1. User creates a distance expense. Transaction stores the rate reference at transaction.comment.customUnit.customUnitRateID = <rateID>. transactionViolations_<txID> is [] — clean. LHN shows no RBR.
2. Admin deletes the distance rate. deletePolicyDistanceRates (or whatever the action is named on main) writes an optimistic Onyx update that removes the rate from policy.customUnits.<unitID>.rates. The policy is now internally inconsistent with the transaction — the transaction's customUnitRateID points at a key that no longer exists in the policy. But the action does not write a matching optimistic update to transactionViolations_<txID>. That's the missing piece.
3. LHN and chat preview re-render. They read from transactionViolations_<txID> (still []) via useOnyx. No violation in the array → no RBR badge, no inline "Rate not valid for this workspace" text. The orphaned rate reference is invisible to these surfaces because they don't recompute violations themselves — they trust the precomputed list.
4. User opens the expense detail page. This mounts the expense detail screen, which calls Report.openReport(reportID). The server's OpenReport handler does a fresh violation pass on every transaction in the report, sees the dangling customUnitRateID, and returns customUnitOutOfPolicy in the response's transactionViolations field. Onyx merges the result → transactionViolations_<txID> now contains the violation → every subsequent render (LHN, preview, detail) shows the error.

That's why "open the expense" is the workaround-by-accident: it's what populates the violations cache that everything else reads from.

The asymmetry to fix: the workspace-side action (delete rate) and the transaction-side state (violations) are linked by a server-computed invariant, but the optimistic-update bookkeeping only handles one side of it. The fix is to teach deletePolicyDistanceRates to also write the consequence of its own action — "every transaction using this rate now has a customUnitOutOfPolicy violation" — into Onyx at the moment of deletion, so the LHN and preview pick it up on the same render tick as the rate disappearing.

Verified vs. hypothesis:

• ✅ Verified: NewDot stores violations per-transaction at transactionViolations_<id> (a ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS entry) and the chat preview / LHN read them via useOnyx — this is the standard pattern in MoneyRequestPreview and ReportPreview.
• ✅ Verified: customUnitOutOfPolicy is the violation name for "transaction's custom unit rate isn't on the policy" — it lives in src/types/onyx/TransactionViolation.ts (or the equivalent violation types file).
• ⚠️ Hypothesis (needs a reviewer to confirm with codebase access): the exact file and function name for the distance-rate delete action. Most likely src/libs/actions/Policy/DistanceRate.ts::deletePolicyDistanceRates, but it could also live under Policy/Policy.ts or a Distance namespace. A grep for DELETE_POLICY_DISTANCE_RATES (the API command name) lands on it.

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

I'd extend the delete-rate action to write optimistic violation updates for every transaction that referenced the deleted rate, and add a symmetric cleanup in the failureData for the offline/rollback case. Two changes:

1. Extend deletePolicyDistanceRates to write optimistic transactionViolations updates. In the action's optimisticData builder:

  function deletePolicyDistanceRates(policyID: string, customUnitID: string, rateIDsToDelete: string[]) {
      // ...existing optimisticData for the policy itself

+     // Every open transaction that was using one of the deleted rates is now
+     // invalid — the transaction's customUnitRateID points at a rate that no
+     // longer exists on the policy. Set the customUnitOutOfPolicy violation
+     // so the LHN, chat preview, and expense preview surface the error
+     // immediately rather than waiting for the user to open the expense
+     // (#90807).
+     const affectedTransactions = Object.values(allTransactions ?? {}).filter(
+         (transaction) =>
+             transaction?.policyID === policyID &&
+             rateIDsToDelete.includes(transaction.comment?.customUnit?.customUnitRateID ?? ''),
+     );
+
+     affectedTransactions.forEach((transaction) => {
+         const existingViolations = allTransactionViolations?.[`${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transaction.transactionID}`] ?? [];
+         const hasOutOfPolicyAlready = existingViolations.some((v) => v.name === CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY);
+         if (hasOutOfPolicyAlready) return;
+
+         optimisticData.push({
+             onyxMethod: Onyx.METHOD.MERGE,
+             key: `${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transaction.transactionID}`,
+             value: [
+                 ...existingViolations,
+                 {name: CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY, type: CONST.VIOLATION_TYPES.VIOLATION},
+             ],
+         });
+     });
  }

The hasOutOfPolicyAlready guard prevents the violation from being added twice if the user somehow deletes a rate, the violation lands, and then the same rate ID gets re-deleted (or a sibling rate gets deleted on the same transaction). The server's response will be authoritative — this is just the optimistic shape.

2. Symmetric rollback in failureData. If the server rejects the delete (the rate couldn't actually be deleted, e.g. permission issue or race), the optimistic violation needs to come back off:

+ // If the delete fails on the server, the rate is still on the policy and
+ // the transaction is valid again — remove the violation we optimistically
+ // added so the UI returns to its pre-delete state.
+ affectedTransactions.forEach((transaction) => {
+     failureData.push({
+         onyxMethod: Onyx.METHOD.MERGE,
+         key: `${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transaction.transactionID}`,
+         value: (allTransactionViolations?.[`${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transaction.transactionID}`] ?? [])
+             .filter((v) => v.name !== CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY),
+     });
+ });

The successData doesn't need to do anything explicit — the server's response will overwrite transactionViolations_<id> with the authoritative list (which should also contain customUnitOutOfPolicy), so the optimistic value gets replaced by the same value. No flicker.

3. Regression test. A small unit test in tests/unit/PolicyDistanceRateTest.ts (or wherever the action is tested) covering the two corners:

describe('deletePolicyDistanceRates — optimistic violations (#90807)', () => {
    it('writes customUnitOutOfPolicy on every affected transaction', async () => {
        await Onyx.set(`transaction_${txID}`, {policyID, comment: {customUnit: {customUnitRateID: rateID}}});
        DistanceRate.deletePolicyDistanceRates(policyID, customUnitID, [rateID]);
        const violations = await Onyx.get(`${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${txID}`);
        expect(violations).toContainEqual(expect.objectContaining({name: CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY}));
    });

    it('does not affect transactions on other policies', async () => {
        await Onyx.set(`transaction_${otherTxID}`, {policyID: 'other', comment: {customUnit: {customUnitRateID: rateID}}});
        DistanceRate.deletePolicyDistanceRates(policyID, customUnitID, [rateID]);
        const violations = await Onyx.get(`${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${otherTxID}`);
        expect(violations).not.toContainEqual(expect.objectContaining({name: CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY}));
    });
});

The second case (cross-policy) catches the most likely regression — accidentally widening the predicate to all transactions instead of just the ones on the affected policy.

4. Verification. Walk the issue's repro:

• Before the fix: delete rate → switch to inbox → no RBR on the workspace LHN entry, no error on the chat preview. Open expense → RBR appears retroactively.
• After the fix: delete rate → switch to inbox → RBR appears immediately on the workspace LHN entry, "Rate not valid for this workspace" appears on the chat preview without needing to open the expense.

What alternative solutions did you explore?

• Fix it backend-side: have DELETE_POLICY_DISTANCE_RATES push transactionViolations updates via Pusher on completion. This is the cleanest invariant — the server owns the policy/violation relationship — but it requires a server deploy and Pusher fan-out for potentially many transactions per delete. The optimistic-client fix lands today and degrades gracefully even when the backend later pushes the same violation (the merge is idempotent on the customUnitOutOfPolicy name). Both are forward-compatible.
• Recompute violations on every render in the chat preview / LHN. Solves the staleness but is wasteful — every report row would call ViolationsUtils.compute() on every render, and the violation calculation isn't free (walks the full policy + transaction tree). The cached transactionViolations Onyx key exists precisely to avoid this.
• Block the rate deletion when there are open transactions using it. A real product question — UX-wise, "you can't delete this rate because there's still an open expense on it" might actually be the right behavior — but that's a design call, not a bug fix. The current behavior (allow delete, mark expenses invalid) is consistent with how Expensify handles category/tag deletes, so it's likely the intended design.
• Use a derived selector that joins transactions and policy.customUnits.rates and computes isRateValid per-transaction. Cleaner long-term architecture (selector-based derived state) but a bigger refactor than this bug warrants. Worth a follow-up but the optimistic-update fix is the right size for this issue.

[mukhrr]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-15 17:51:48 UTC.

Proposal

What is the root cause of that problem?

There are two independent issues both contributing to the missing RBR.

1. The optimistic violation push aborts early when deleting a rate.

deletePolicyDistanceRates is supposed to optimistically attach customUnitOutOfPolicy to every transaction that was using the deleted rate. The loop that builds those updates has a return where a continue was intended, so as soon as any inspected transaction already carries the violation we exit the function entirely — and the API.write(DELETE_POLICY_DISTANCE_RATES, …) call at the bottom never fires:

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

Lines 447 to 471 in 03f9fb6

	for (const transactionID of transactionIDsAffected) {
	const currentTransactionViolations = transactionViolations?.[`${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transactionID}`] ?? [];
	if (currentTransactionViolations.some((violation) => violation.name === CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY)) {
	return;
	}
	optimisticTransactionsViolations.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transactionID}`,
	value: [
	...currentTransactionViolations,
	{
	type: CONST.VIOLATION_TYPES.VIOLATION,
	name: CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY,
	showInReview: true,
	},
	],
	});
	failureTransactionsViolations.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transactionID}`,
	value: currentTransactionViolations,
	});
	}

That's what produces the "Rate not valid for this workspace" error on the expense preview only appearing once the user opens the expense — OpenReport is what eventually causes the BE to push the violation back to Onyx.

2. The workspace‑chat RBR is intentionally suppressed by the green Submit badge.

Even once the optimistic violation lands, the LHN row for the workspace expense chat still stays green/Submit. reportAttributes derives the row's brick‑road status via:

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

Lines 300 to 320 in 03f9fb6

	// When the report is ready to submit, always show the green Submit badge
	// regardless of violations — the user can submit without fix.
	const willShowGreenSubmit = requiresAttention && actionGreenBadge === CONST.REPORT.ACTION_BADGE.SUBMIT;
	// if report has errors or violations, show red dot
	// Also skip setting ERROR when we'll show the green Submit badge — let the user submit without fix.
	if (reasonAndReportAction && !willShowGreenSubmit) {
	needsParentChatErrorPropagation = true;
	// RBR/Fix mirrors GBR's access rule: only show on the child when the user can't already
	// see it on the parent workspace chat. The parent still gets ERROR/FIX through the
	// propagation loop below, so the actionable indicator surfaces on the workspace chat row
	// (which is where C+ wants it). Skips when the chat parent isn't accessible to the user.
	const chatPolicy = chatReport?.policyID ? policies?.[`${ONYXKEYS.COLLECTION.POLICY}${chatReport.policyID}`] : undefined;
	const isChildOfAccessiblePolicyExpenseChat = !!chatReport && isPolicyExpenseChat(chatReport) && (!!chatReport.isOwnPolicyExpenseChat || isPolicyAdmin(chatPolicy));
	if (!isChildOfAccessiblePolicyExpenseChat) {
	brickRoadStatus = CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR;
	actionBadge = CONST.REPORT.ACTION_BADGE.FIX;
	actionTargetReportActionID = reasonAndReportAction.reportAction?.reportActionID;
	}
	}

willShowGreenSubmit short‑circuits the needsParentChatErrorPropagation branch whenever the report is in a submit‑ready state, so the parent chat never gets its brickRoadStatus flipped to ERROR — even when the child expense report has a blocking violation. The previous Submit‑priority refactor (2d891e0eb7d) made this explicit: "always show the green Submit badge regardless of violations." With this rule in place, customUnitOutOfPolicy cannot surface on the chat row.

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

Fix 1 — don't bail out of the deletion loop:

     for (const transactionID of transactionIDsAffected) {
         const currentTransactionViolations = transactionViolations?.[`${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transactionID}`] ?? [];
         if (currentTransactionViolations.some((violation) => violation.name === CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY)) {
-            return;
+            continue;
         }

Fix 2 — let blocking violations take precedence over the green Submit badge:

-                // When the report is ready to submit, always show the green Submit badge
-                // regardless of violations — the user can submit without fix.
-                const willShowGreenSubmit = requiresAttention && actionGreenBadge === CONST.REPORT.ACTION_BADGE.SUBMIT;
+                // When the report is ready to submit, show the green Submit badge — unless there are
+                // blocking violations/field violations that need to be fixed before submission can succeed.
+                const willShowGreenSubmit =
+                    requiresAttention && actionGreenBadge === CONST.REPORT.ACTION_BADGE.SUBMIT && !hasAnyViolations && !hasFieldViolations;

Worth noting in the PR description: Fix 2 walks back the Submit‑priority behavior introduced in 2d891e0eb7d and will likely require updating the perf‑test baseline that refactor was protecting. Additionally, I'd suggest computing transactionIDsAffected inside deletePolicyDistanceRates (resolved from ONYXKEYS.COLLECTION.TRANSACTION by rate ID) rather than asking each caller to supply it via useOnyx selectors — that protects against the secondary failure mode where the caller's eligibleTransactionIDs is undefined/empty at click time and the optimistic violation is silently skipped.

What alternative solutions did you explore? (Optional)

N/A

Demo:

demo.mp4

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-15 17:55:33 UTC.

Proposal

What is the root cause of that problem?

When a distance rate is deleted, deletePolicyDistanceRates optimistically marks the rate as deleted on the policy and tries to push a customUnitOutOfPolicy violation for each affected transaction. The loop is broken:

for (const transactionID of transactionIDsAffected) {
    const currentTransactionViolations = transactionViolations?.[`${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transactionID}`] ?? [];
    if (currentTransactionViolations.some((violation) => violation.name === CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY)) {
        return; // ← exits the whole function, skipping API.write entirely
    }
    ...
}

This was introduced in 9e9bfc7f9fd "Removed Onyx.connect from DistanceRate Actions (part 1)" — the original code used forEach((transaction) => { ... return; ... }) where return skipped the iteration. The refactor switched to for...of but kept return, which now bails out of deletePolicyDistanceRates mid-flight, so optimisticData.push(...optimisticTransactionsViolations) and the API.write after the loop never run.

Even when the loop finishes (no pre-existing violation), there's a second structural problem: the optimistic policy update marks the rate as {enabled: false, pendingAction: 'delete'} but leaves it in policy.customUnits[unitID].rates. getViolationsOnyxData treats any rate that's still in rates as valid and rejects the violation:

const customRate = isPerDiem ? getPerDiemRateCustomUnitRate(policy, customUnitRateID) : getDistanceRateCustomUnitRate(policy, customUnitRateID);
if (customRate) {
    newTransactionViolations = reject(newTransactionViolations, {name: CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY});
} else {
    newTransactionViolations.push({name: CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY, ...});
}

So any subsequent transaction update that re-runs getViolationsOnyxData between the optimistic delete and the API response (e.g. an unrelated edit, a violation rebuild from another action) silently strips the violation again — which is why the RBR is unstable in the LHN/workspace chat but the MoneyRequestView page still surfaces the error via its independent isDistanceRequest && !rate fallback.

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

1. Stop bailing out of the function on a pre-existing violation — skip just that transaction:

     for (const transactionID of transactionIDsAffected) {
         const currentTransactionViolations = transactionViolations?.[`${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transactionID}`] ?? [];
         if (currentTransactionViolations.some((violation) => violation.name === CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY)) {
-            return;
+            continue;
         }

2. Teach getDistanceRateCustomUnitRate/getPerDiemRateCustomUnitRate (or the call site in getViolationsOnyxData) to ignore rates marked for deletion, so the rate-still-in-policy state during the optimistic window doesn't strip the just-added violation:

 function getDistanceRateCustomUnitRate(policy: OnyxEntry<Policy>, customUnitRateID: string): Rate | undefined {
     const distanceUnit = getDistanceRateCustomUnit(policy);
-    return distanceUnit?.rates[customUnitRateID];
+    const rate = distanceUnit?.rates[customUnitRateID];
+    return rate?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE ? undefined : rate;
 }

After (1) + (2), deletePolicyDistanceRates can drop its bespoke violation push and instead build optimistic/failure transaction-violation onyxData by calling ViolationsUtils.getViolationsOnyxData once per affected transaction against the optimistic policy (rate marked pendingAction: 'delete'). Because getViolationsOnyxData now correctly treats the rate as gone, it returns the customUnitOutOfPolicy violation — and on API failure the same helper, run against the restored policy, produces the inverse update for failureData. This collapses the buggy loop into the canonical pattern used by every other policy-driven violation update in the codebase (buildOptimisticViolationsForPolicy for category/tag changes; UpdateMoneyRequest, BulkEdit, Receipt for transaction edits).

It also removes the requirement that callers (PolicyDistanceRateDetailsPage, PolicyDistanceRatesPage) pass transactionIDsAffected and transactionViolations — the action can derive them itself from the in-action getAllTransactions() helper, which also fixes the case where the caller's eligibleTransactionIDs selector returns an empty set before policyReports has hydrated.

What alternative solutions did you explore?

• Only swap return → continue. Minimal patch, but it leaves the structural inconsistency from (2): the violation can still be silently rejected later by any path that recomputes getViolationsOnyxData while the rate is in its pendingAction: 'delete' window. Rejected as fragile.
• Filter pendingAction === 'delete' rates only inside getViolationsOnyxData rather than in the shared helpers. Avoids touching shared utils but every consumer of getDistanceRateCustomUnitRate that cares about validity (e.g. distance-request RBR fallback in MoneyRequestView) would need the same patch. Rejected as duplication-prone.
• Add successData that clears the rate from policy.customUnits[unitID].rates. Would also make getViolationsOnyxData see the rate as gone, but it diverges from the BE response shape (BE owns the post-delete policy snapshot) and risks fighting the server reply.

[melvin-bot]

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

[KJ21-ENG]

Proposal

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

After a workspace admin deletes a custom distance rate that is already used by a distance expense, the workspace chat preview does not immediately show the RBR / "Rate not valid for this workspace" error. The error appears only after the user opens the expense details.

What is the root cause of that problem?

The delete flow already tries to add an optimistic customUnitOutOfPolicy violation for affected transactions in deletePolicyDistanceRates(). The problem is how the distance-rate settings pages build the transactionIDsAffected list before calling it.

Both PolicyDistanceRatesPage and PolicyDistanceRateDetailsPage first build a policyReports set from loaded reports with report.policyID === policyID, then only treat a transaction as affected when transaction.reportID exists and policyReports.has(transaction.reportID).

That makes the optimistic violation depend on the expense report already being present in the local report cache. In the reported flow, the workspace chat can render the expense preview from the report action / transaction data, but the full expense report relationship is not guaranteed to be hydrated until opening the expense. So when the rate is deleted from settings, transactionIDsAffected can be empty, no TRANSACTION_VIOLATIONS update is queued, and the preview stays clean. Opening the expense loads enough report/violation data for the existing customUnitOutOfPolicy logic to run, which is why the RBR and invalid-rate message appear only then.

Evidence:

• deletePolicyDistanceRates() only adds the optimistic customUnitOutOfPolicy violation for IDs passed in transactionIDsAffected.
• The list page selector requires transaction.reportID && policyReports?.has(transaction.reportID) before adding a matching distance transaction.
• The details page selector uses the same report-cache requirement.
• The generic violation calculation already treats a missing/disabled custom unit rate as customUnitOutOfPolicy, so the delayed state is not a missing validation rule; it is a missing optimistic affected-transaction list.

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

Build the affected transaction list from the transaction's stored custom unit data, not from the local report cache.

Concretely:

1. In PolicyDistanceRatesPage, remove the policyReports dependency from transactionsSelector. A transaction should be included when:
   • transaction.comment.customUnit.customUnitID === customUnit.customUnitID
   • transaction.comment.customUnit.customUnitRateID is one of the selected/deletable rate IDs
2. In PolicyDistanceRateDetailsPage, make the same change for the single-rate selector: match by customUnitID and customUnitRateID === rateID, without requiring transaction.reportID to resolve to a loaded policy report.
3. Keep passing those affected IDs into deletePolicyDistanceRates(), so its existing optimistic TRANSACTION_VIOLATIONS update immediately drives the workspace chat RBR and preview error.
4. Add focused coverage for the selector/helper behavior, preferably by extracting the affected-distance-transaction matcher into a small utility and testing that it includes matching distance transactions even when transaction.reportID is missing or the report is not loaded.

This keeps the fix scoped to the delete-rate optimistic update path. It does not change the backend validation, the generic customUnitOutOfPolicy rule, unrelated category/tag violations, or preview rendering rules.

What alternative solutions did you explore? (Optional)

We could make TransactionPreview synthesize customUnitOutOfPolicy directly from transaction.comment.customUnit.customUnitRateID and the current policy. That would mask this specific preview symptom, but it would duplicate violation logic in the preview layer and still leave the delete action's optimistic violation update incomplete. Fixing the affected-transaction discovery at the source is narrower and keeps the existing RBR pipeline working as intended.

[melvin-bot]

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

[oqildev]

Proposal

What is the root cause of that problem?

When a distance rate is deleted from workspace settings, the code is supposed to flag every expense that still references that rate with a
customUnitOutOfPolicy violation, so the workspace chat shows an RBR and the expense preview shows "Rate not valid for this workspace"
immediately. I traced the path and found the violation never reaches Onyx in the bug's repro — the fallback UI in the expense details is the
only thing surfacing the error, which is why it looks like "you have to open the expense first."

File → function → line chain

1. deletePolicyDistanceRates in src/libs/actions/Policy/DistanceRate.ts is the only delete entry point (called from
   PolicyDistanceRateDetailsPage.deleteRate and PolicyDistanceRatesPage.deleteRates). It builds the optimistic-violation Onyx updates inside a
   for...of loop:
   https://github.com/Expensify/App/blob/main/src/libs/actions/Policy/DistanceRate.ts#L447-L471

2. Inside that loop, lines 449–451 do an early bailout:
   https://github.com/Expensify/App/blob/main/src/libs/actions/Policy/DistanceRate.ts#L449-L451
   This was originally a forEach callback (commit b0701482795 "fix: no RBR when deleting distance rates"), where return meant "skip this
   iteration." The Onyx.connect-removal refactor (commit 411c90b8d2a) converted the callback into a for...of loop but kept the return
   literal. In a for...of loop, return exits the enclosing function — so the moment one affected transaction already carries
   CUSTOM_UNIT_OUT_OF_POLICY, the function aborts before:

   • pushing optimistic violations for the rest of transactionIDsAffected,
   • appending those updates to optimisticData/failureData,
   • and crucially, calling API.write(WRITE_COMMANDS.DELETE_POLICY_DISTANCE_RATES, ...) at line 482. The server never hears about the delete,
     and no violation is written for any affected transaction.

3. Even when the loop completes, this delete path never invokes the canonical violation engine ViolationsUtils.getViolationsOnyxData, which
   is the function that actually decides whether CUSTOM_UNIT_OUT_OF_POLICY should be on a transaction (by looking up
   getDistanceRateCustomUnitRate(policy, customUnitRateID)):
   https://github.com/Expensify/App/blob/main/src/libs/Violations/ViolationsUtils.ts#L433-L446
   That code only runs on transaction edits (UpdateMoneyRequest, Transaction, BulkEdit, Receipt, MoneyRequestBuilder). Deleting the
   rate changes the policy but does not re-run the violation engine against the transactions that referenced the rate — so the violation goes
   missing from transactionViolations_<id>, which is exactly what the LHN RBR (ReportUtils.getViolatingReportIDForRBRInLHN) and the chat
   preview read.

4. The reason the error seems to "appear after opening the expense" is the presentational fallback in MoneyRequestView:
   https://github.com/Expensify/App/blob/main/src/components/ReportActionItem/MoneyRequestView.tsx#L465-L466
   const isCustomUnitOutOfPolicy =
   (transactionViolations.some(... CUSTOM_UNIT_OUT_OF_POLICY) || (isDistanceRequest && !rate)) && !isTrackExpense;

The (isDistanceRequest && !rate) branch resolves rate against the freshly updated policy, finds nothing, and renders the error in the
detail view. That branch only runs at render-time inside MoneyRequestView and never writes to Onyx, so the LHN and the preview keep showing
no RBR. The persistent RBR a user sees after closing the detail view comes from the OpenReport/OpenTransaction round-trip that fetches
server-recomputed violations — i.e., the server is doing what the client should have done locally on delete.

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

the moment the policy state changes and the affected transactions become out-of-policy. Doing it here means a single Onyx write makes the LHN
RBR, the chat preview, and the detail view consistent without depending on a server round-trip.

Concretely:

1. Replace the return at line 449 with continue. Same intent as the original forEach callback (skip this transaction if it already
   has the violation), without aborting the whole function. This alone restores the policy delete API call and the optimistic violations for
   transactions that don't yet have the violation.

2. Replace the bespoke "push CUSTOM_UNIT_OUT_OF_POLICY" block (lines 447–471) with a call into ViolationsUtils.getViolationsOnyxData per
   affected transaction, passing a synthesized "post-delete" policy where customUnits[customUnitID].rates[rateID] is removed (or enabled: false, matching what the optimistic policy update at line 416–428 already does). Merge the returned onyxData into
   optimisticData/failureData. This way the same engine that runs on transaction edits decides the violations on delete — no duplicated logic,
   no drift, and removed/cleared violations are handled too (reject(..., {name: CUSTOM_UNIT_OUT_OF_POLICY}) at line 438), which matters when an
   admin deletes the rate and then re-enables it before the API call resolves.

3. Edge cases to weave in:

• Offline: optimistic write is the only signal until reconnection — so it has to be complete (not bypassed by the return).
• Failure rollback: the existing failureData snapshot of currentTransactionViolations is fine; just make sure it's pushed for every
  transaction we touched (currently it isn't, because the same return skips failureTransactionsViolations.push too).
• Bulk delete from PolicyDistanceRatesPage.deleteRates passes the union of rateIDToTransactionIDsMap for the selected rates — the engine
  call should remove all of them from the synthesized policy at once, so transactions that referenced any deleted rate get recomputed
  correctly.
• Reports that are already closed/approved: ViolationsUtils.getViolationsOnyxData already gates by report state; deferring to it avoids
  re-introducing violations on settled transactions.

4. MoneyRequestView's (isDistanceRequest && !rate) fallback can stay — it's a useful belt-and-suspenders for receipts mid-flight — but it
   should no longer be the only reason the user ever sees the error.

What alternative solutions did you explore? (Optional)

• Just change return to continue and stop there. Rejected — it fixes the abort-bailout in step 1, but the bespoke optimistic push only
  adds the violation; it never removes it when the rate later becomes valid again, and it doesn't recompute any other client-side violation
  impacted by the policy change. Drift between this code path and ViolationsUtils.getViolationsOnyxData is what made the original "no RBR" fix
  (commit b0701482795) necessary in the first place.

• Fix it only in the LHN/preview by adding an (isDistanceRequest && !rate) lookup there. Rejected — getViolatingReportIDForRBRInLHN is
  driven entirely by transactionViolations (see src/libs/ReportUtils.ts#L9087-L9162); pushing rate lookups into LHN selectors would re-query
  every policy/customUnit per render for every report in the sidebar, and it still leaves the offline rollback story inconsistent with the
  server.

• Recompute violations on the report itself when the policy changes (e.g., a derived Onyx selector). Deferred out-of-scope — the right
  long-term direction, but it's a much bigger change. The targeted fix above is correct for this bug.