Distance Rate - Rate out of policy violation shown briefly after employee change distance

[neil-marcellini]

Action Performed:

Preconditions: Prepare two accounts (Admin & Employee)

• As an admin, open a Collect or Control workspace and go to the workspaces settings, then the distance rates page
• Add a second distance rate named Old rate with any differing amount and keep it enabled.
• As an employee on that workspace, create a distance expense and select the Default rate.

Steps: Perform on ND

1. Log in as the employee and open the expense
2. Switch the rate to Old rate
3. As the admin in an incognito/other window, disable the rate
4. As the employee change its distance (or edit a waypoint) and save

Expected Result:

Verify the edit saves with no error and the amount recalculates using Old rate.

Actual Result:

After changing the distance and save, Rate out of policy violation shown briefly then disappear and all back to normal

Workaround:

Unknown

Platform:

• Web

• PR link: https://github.com/Expensify/Web-Expensify/pull/54303

• Is this issue reproducible in staging, production or both? Yes, repro in both

• Notes/Photos/Videos:

628279783-ed53d3fd-614d-4340-b709-313cd589d1aa.mp4

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022084773250870245287
• Upwork Job ID: 2084773250870245287
• Last Price Increase: 2026-08-04

Issue Owner

Current Issue Owner: @aldo-expensify

[melvin-bot]

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

[melvin-bot]

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

[Dip-G-Git]

Proposal

What is the root cause of that problem?

• provide code snippet
• Primary Root Cause: src/libs/actions/IOU/UpdateMoneyRequest.ts, inside getUpdateMoneyRequestParams, the optimistic-violation recompute block. When the employee edits distance/waypoints, the code strips a fixed allow‑list of distance violations and then hands the remaining set to ViolationsUtils.getViolationsOnyxData:

if (hasModifiedDistanceRate || hasModifiedDistance || hasPendingWaypoints) {
    // Clear stale distance-related violations while the server reprocesses.
    // The server will re-evaluate and re-add any that legitimately apply.
    optimisticViolations = optimisticViolations.filter(
        (violation) =>
            !(violation.name === CONST.VIOLATIONS.MODIFIED_AMOUNT && violation.data?.type === CONST.MODIFIED_AMOUNT_VIOLATION_DATA.DISTANCE) &&
            violation.name !== CONST.VIOLATIONS.INCREASED_DISTANCE,
    );
}
...
const violationsOnyxData = ViolationsUtils.getViolationsOnyxData({
    updatedTransaction,
    transactionViolations: optimisticViolations,
    policy,
    ...
    distanceOriginalPolicy,
});
optimisticData.push(violationsOnyxData);

Why: the filter only clears MODIFIED_AMOUNT (distance) and INCREASED_DISTANCE. It does not clear the "rate out of policy" violation for a disabled/out-of-date-range custom-unit rate. getViolationsOnyxData is then called with the employee's stale local copy of the policy, in which the admin's just-disabled "Old rate" is still enabled. Because the local policy still shows the rate as valid, the recompute produces a violation set that momentarily re-derives the out-of-policy flag before the server response arrives and reconciles — producing the "shown briefly then disappears" flash.

• Secondary Root Cause: src/libs/actions/IOU/UpdateMoneyRequest.ts, getUpdateTrackExpenseParams — the same class of bug on the track-expense path. It calls syncCustomUnitRateOutOfDateRangeViolation(...) only when hasModifiedDistanceRate || hasModifiedCreated || hasModifiedDate, never on a pure distance/waypoint edit:

const optimisticViolations = hasModifiedDistanceRate
    ? transactionViolationsList.filter((violation) => violation.name !== CONST.VIOLATIONS.CUSTOM_UNIT_RATE_OUT_OF_DATE_RANGE)
    : transactionViolationsList;
syncedOptimisticViolations = syncCustomUnitRateOutOfDateRangeViolation(optimisticViolations, updatedTransaction, policyForTransaction);

Why: distance edits skip the rate-out-of-range re-sync entirely, so a stale rate violation survives locally until server reconciliation.

• Affected Files: src/libs/actions/IOU/UpdateMoneyRequest.ts (the optimisticViolations filter block inside getUpdateMoneyRequestParams; the optimisticViolations derivation inside getUpdateTrackExpenseParams).
• Affected Component(s): getUpdateMoneyRequestParams / getUpdateTrackExpenseParams optimistic-violation pipeline → MoneyRequestView violation banner render.
• Bug Category: Model-vs-reality divergence + incomplete optimistic-clear allow-list (stale-cache race). The employee's local policy is stale (rate still enabled) while the server has it disabled; the optimistic recompute trusts the stale model and the clear-list omits the rate violation.
• Mechanism:
  1. Admin disables "Old rate" server-side; the employee's Onyx policy copy is not yet updated (still enabled).
  2. Employee edits distance → updateMoneyRequestDistance → getUpdateMoneyRequestParams with distance/waypoints in transactionChanges.
  3. hasModifiedDistance/hasPendingWaypoints is true, so the optimisticViolations filter runs — but it removes only MODIFIED_AMOUNT(distance) and INCREASED_DISTANCE, not the rate-out-of-policy violation.
  4. ViolationsUtils.getViolationsOnyxData recomputes against the stale local policy and pushes an optimistic violations write; because the local rate still validates against a now-different amount, the out-of-policy flag flashes.
  5. optimisticData.push(violationsOnyxData) writes it → MoneyRequestView renders the banner briefly.
  6. Server success/Pusher push delivers the authoritative (correct) violation set → banner disappears.

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

• provide code snippet

• Fix Option 1 (Recommended): src/libs/actions/IOU/UpdateMoneyRequest.ts, inside the if (hasModifiedDistanceRate || hasModifiedDistance || hasPendingWaypoints) block of getUpdateMoneyRequestParams. Add the rate-out-of-policy / custom-unit-out-of-date-range violation to the optimistic clear-list so a distance edit stops re-flagging a rate the server is already reprocessing.

  Before:

  optimisticViolations = optimisticViolations.filter(
      (violation) =>
          !(violation.name === CONST.VIOLATIONS.MODIFIED_AMOUNT && violation.data?.type === CONST.MODIFIED_AMOUNT_VIOLATION_DATA.DISTANCE) &&
          violation.name !== CONST.VIOLATIONS.INCREASED_DISTANCE,
  );

  After (concept — clear the rate violation too, matching the existing hasModifiedDistanceRate branch already used above):

  optimisticViolations = optimisticViolations.filter(
      (violation) =>
          !(violation.name === CONST.VIOLATIONS.MODIFIED_AMOUNT && violation.data?.type === CONST.MODIFIED_AMOUNT_VIOLATION_DATA.DISTANCE) &&
          violation.name !== CONST.VIOLATIONS.INCREASED_DISTANCE &&
          violation.name !== CONST.VIOLATIONS.CUSTOM_UNIT_RATE_OUT_OF_DATE_RANGE,
  );

  Why best: it's the exact deepest point where the stale violation is passed forward, it mirrors the pattern the file already uses for the rate-change path (optimisticViolations.filter((v) => v.name !== CONST.VIOLATIONS.CUSTOM_UNIT_RATE_OUT_OF_DATE_RANGE)), and it lets the server remain the source of truth. It solves the flash because the recompute no longer carries the stale rate violation into getViolationsOnyxData.

• Fix Option 2 (Alternative): src/libs/actions/IOU/UpdateMoneyRequest.ts, in getUpdateTrackExpenseParams, broaden the sync condition to also cover distance edits:

  Before: hasModifiedDistanceRate || hasModifiedCreated || hasModifiedDate gates the syncCustomUnitRateOutOfDateRangeViolation call.
  After: also include a hasModifiedDistance/hasPendingWaypoints term so the track-expense path re-syncs the rate violation on a pure distance edit.

  Trade-off: covers the self-DM/track path (needed for completeness) but is secondary — the reported repro is a workspace expense, which flows through Option 1's path.

• Revert Option: Revert Web-Expensify PR mWeb - Back button on workspace chat returns to workspace list instead of workspace settings #54303 (the linked rate/violation change). Not ideal: it would remove the intended server behavior and reintroduce whatever it was fixing; the flash is a front-end optimistic issue, not a server one.

• Alternate fix (rejected): Force-refresh the employee's policy before recompute. Rejected: heavy, racy, and the server already re-evaluates violations — the front end only needs to stop optimistically re-adding the stale one.

Fix	Description	Files to Change	Effort	Risk	Status
1	Add CUSTOM_UNIT_RATE_OUT_OF_DATE_RANGE to the optimistic clear-list in getUpdateMoneyRequestParams distance-edit branch	src/libs/actions/IOU/UpdateMoneyRequest.ts	Low	Low	Recommended
2	Extend getUpdateTrackExpenseParams sync condition to cover distance/waypoint edits	src/libs/actions/IOU/UpdateMoneyRequest.ts	Low	Low	Alternative
3	Revert Web-Expensify #54303	Web-Expensify	Med	High	Rejected

What alternative solutions did you explore? (Optional)

• Add only the m flag — matches the line but still erases the title (rejected above).
• Move the subtitle to its own label on the server — leaves old charts broken and keeps the App brittle.
• Revert the localizer — restores the original wrong behavior.

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[melvin-bot]

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

[samranahm]

🚨 Edited by proposal-police: This proposal was edited at 2026-08-04 23:10:26 UTC.

Proposal

What is the root cause of that problem?

When an employee edits distance or waypoints on an existing workspace distance expense whose selected rate was later disabled by an admin, the UI briefly shows "Rate out of policy", then the banner disappears after the server responds. The amount correctly recalculates using the still-selected Old rate. The flash is an optimistic client bug, not a wrong final server state.

Editing distance goes through getUpdateMoneyRequestParams, which rebuilds optimistic violations via ViolationsUtils.getViolationsOnyxData before the API returns:

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

Lines 2024 to 2089 in 4331690

	const isInvoice = isInvoiceReportReportUtils(iouReport);
	if (
	transactionID &&
	policy &&
	isGroupPolicy(policy) &&
	!isInvoice &&
	updatedTransaction &&
	(hasPendingWaypoints ||
	hasModifiedTag ||
	hasModifiedCategory ||
	hasModifiedComment ||
	hasModifiedMerchant ||
	hasModifiedDistanceRate ||
	hasModifiedDistance ||
	hasModifiedDate ||
	hasModifiedCurrency ||
	hasModifiedAmount ||
	hasModifiedCreated ||
	hasModifiedReimbursable ||
	hasModifiedTaxCode ||
	hasModifiedAttendees)
	) {
	const currentTransactionViolations = violations ?? [];
	// If the amount, currency or date have been modified, we remove the duplicate violations since they would be out of date as the transaction has changed
	let optimisticViolations =
	hasModifiedAmount || hasModifiedDate || hasModifiedCurrency
	? currentTransactionViolations.filter((violation) => violation.name !== CONST.VIOLATIONS.DUPLICATED_TRANSACTION)
	: currentTransactionViolations;
	optimisticViolations =
	hasModifiedCategory && transactionChanges.category === ''
	? optimisticViolations.filter((violation) => violation.name !== CONST.VIOLATIONS.CATEGORY_OUT_OF_POLICY)
	: optimisticViolations;
	if (hasModifiedDistanceRate) {
	optimisticViolations = optimisticViolations.filter((violation) => violation.name !== CONST.VIOLATIONS.CUSTOM_UNIT_RATE_OUT_OF_DATE_RANGE);
	}
	// Clearing the tag can't be "out of policy"; strip it here since the recompute skips tag logic when tags
	// aren't required and the tag is now empty, which would otherwise leave the stale violation offline.
	optimisticViolations =
	hasModifiedTag && transactionChanges.tag === '' ? optimisticViolations.filter((violation) => violation.name !== CONST.VIOLATIONS.TAG_OUT_OF_POLICY) : optimisticViolations;
	if (hasPendingWaypoints) {
	optimisticViolations = optimisticViolations.filter((violation) => violation.name !== CONST.VIOLATIONS.NO_ROUTE);
	}
	if (hasModifiedDistanceRate || hasModifiedDistance || hasPendingWaypoints) {
	// Clear stale distance-related violations while the server reprocesses.
	// The server will re-evaluate and re-add any that legitimately apply.
	optimisticViolations = optimisticViolations.filter(
	(violation) =>
	!(violation.name === CONST.VIOLATIONS.MODIFIED_AMOUNT && violation.data?.type === CONST.MODIFIED_AMOUNT_VIOLATION_DATA.DISTANCE) &&
	violation.name !== CONST.VIOLATIONS.INCREASED_DISTANCE,
	);
	}
	const violationsOnyxData = ViolationsUtils.getViolationsOnyxData({
	updatedTransaction,
	transactionViolations: optimisticViolations,
	policy,
	policyTagList: policyTagList ?? {},
	policyCategories: policyCategories ?? {},
	hasDependentTags: hasDependentTags(policy, policyTagList ?? {}),
	isInvoiceTransaction: isInvoice,
	isSelfDM: isSelfDM(iouReport),
	iouReport,
	ownerLogin: iouReportOwnerLogin,
	isFromExpenseReport,
	distanceOriginalPolicy,
	});

Inside getViolationsOnyxData, a selected rate that is still on the policy but enabled: false falls into the else branch and newly pushes CUSTOM_UNIT_OUT_OF_POLICY:

App/src/libs/Violations/ViolationsUtils.ts

Lines 663 to 677 in 4331690

	const customRate = isPerDiem ? getPerDiemRateCustomUnitRate(policy, customUnitRateID) : getDistanceRateCustomUnitRate(policyForCustomUnitRate, customUnitRateID);
	if (customRate && customRate.enabled !== false) {
	newTransactionViolations = reject(newTransactionViolations, {name: CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY});
	newTransactionViolations = syncCustomUnitRateOutOfDateRangeViolation(newTransactionViolations, updatedTransaction, policyForCustomUnitRate);
	} else if (isSelfDM && isDistanceRequestForCustomUnit) {
	newTransactionViolations = reject(newTransactionViolations, {name: CONST.VIOLATIONS.CUSTOM_UNIT_RATE_OUT_OF_DATE_RANGE});
	newTransactionViolations = reject(newTransactionViolations, {name: CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY});
	} else {
	newTransactionViolations = reject(newTransactionViolations, {name: CONST.VIOLATIONS.CUSTOM_UNIT_RATE_OUT_OF_DATE_RANGE});
	newTransactionViolations.push({
	name: CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY,
	type: CONST.VIOLATION_TYPES.VIOLATION,
	showInReview: true,
	});
	}

That violation name maps to the "Rate out of policy" label:

App/src/CONST/index.ts

Line 6418 in 4331690

CUSTOM_UNIT_OUT_OF_POLICY: 'customUnitOutOfPolicy',

App/src/languages/en.ts

Line 487 in 4331690

rateOutOfPolicy: 'Rate out of policy',

The server then returns a violation set that keeps Old rate and does not keep that optimistic flag, so the banner clears. Filtering the input violation list in getUpdateMoneyRequestParams cannot stop this, because the producer re-derives CUSTOM_UNIT_OUT_OF_POLICY from policy state regardless of what was filtered out. The employee did not change customUnitRateID; the selected rate should stay Old rate for the amount recalculation.

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

1. In ViolationsUtils.getViolationsOnyxData, add an optional shouldGrandfatherDisabledCustomUnitRate flag. When it is true and the selected rate is present on the policy but disabled, do not newly push CUSTOM_UNIT_OUT_OF_POLICY. Leave any already-present violation untouched. If the rate is absent or deleted, keep today's behavior and still flag it.

App/src/libs/Violations/ViolationsUtils.ts

Lines 670 to 677 in 4331690

	} else {
	newTransactionViolations = reject(newTransactionViolations, {name: CONST.VIOLATIONS.CUSTOM_UNIT_RATE_OUT_OF_DATE_RANGE});
	newTransactionViolations.push({
	name: CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY,
	type: CONST.VIOLATION_TYPES.VIOLATION,
	showInReview: true,
	});
	}

2. In getUpdateMoneyRequestParams, pass shouldGrandfatherDisabledCustomUnitRate: !hasModifiedDistanceRate into getViolationsOnyxData. That covers distance, waypoint, and other non-rate edits that recompute optimistic violations while the employee keeps the previously selected rate. When customUnitRateID itself changes, keep validating against the disabled/absent rate.

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

Lines 2056 to 2089 in 4331690

	if (hasModifiedDistanceRate) {
	optimisticViolations = optimisticViolations.filter((violation) => violation.name !== CONST.VIOLATIONS.CUSTOM_UNIT_RATE_OUT_OF_DATE_RANGE);
	}
	// Clearing the tag can't be "out of policy"; strip it here since the recompute skips tag logic when tags
	// aren't required and the tag is now empty, which would otherwise leave the stale violation offline.
	optimisticViolations =
	hasModifiedTag && transactionChanges.tag === '' ? optimisticViolations.filter((violation) => violation.name !== CONST.VIOLATIONS.TAG_OUT_OF_POLICY) : optimisticViolations;
	if (hasPendingWaypoints) {
	optimisticViolations = optimisticViolations.filter((violation) => violation.name !== CONST.VIOLATIONS.NO_ROUTE);
	}
	if (hasModifiedDistanceRate || hasModifiedDistance || hasPendingWaypoints) {
	// Clear stale distance-related violations while the server reprocesses.
	// The server will re-evaluate and re-add any that legitimately apply.
	optimisticViolations = optimisticViolations.filter(
	(violation) =>
	!(violation.name === CONST.VIOLATIONS.MODIFIED_AMOUNT && violation.data?.type === CONST.MODIFIED_AMOUNT_VIOLATION_DATA.DISTANCE) &&
	violation.name !== CONST.VIOLATIONS.INCREASED_DISTANCE,
	);
	}
	const violationsOnyxData = ViolationsUtils.getViolationsOnyxData({
	updatedTransaction,
	transactionViolations: optimisticViolations,
	policy,
	policyTagList: policyTagList ?? {},
	policyCategories: policyCategories ?? {},
	hasDependentTags: hasDependentTags(policy, policyTagList ?? {}),
	isInvoiceTransaction: isInvoice,
	isSelfDM: isSelfDM(iouReport),
	iouReport,
	ownerLogin: iouReportOwnerLogin,
	isFromExpenseReport,
	distanceOriginalPolicy,
	});

3. Leave setPolicyDistanceRatesEnabled, deletePolicyDistanceRates, create/move flows, and self-DM track-expense behavior unchanged. Admin disable/delete should not be weakened; only optimistic recomputes for edits that do not change the rate should grandfather a present-but-disabled selection.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.