[$250] Rate-Exclude Commute unit remains mi after switching to kilometres until setting is re-saved

[applause-bot]

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

---

Version Number: V9.4.34
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #95483
Email or phone of affected tester (no customers): Applausetester+nrusimha@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redmi note 10s android 13
App Component: User Settings

Action Performed:

1. Login with expensifail account
2. Go to workspace settings - enable distance rate
3. Tap settings - tap exclude commutes-exclude a fixed distance - enter a distance & save
4. Tap unit - change to kilometres
5. Note Exclude commute shows mi
6. Open exclude commute and note kilometres is updated
7. Navigate to settings and note mi is still shown
8. Go to exclude commute and save the distance again
9. Note now unit updated to km

Expected Result:

The Exclude Commute setting should immediately display km after the distance unit is changed to kilometres, without requiring the distance to be re-saved.

Actual Result:

After changing the distance unit to kilometres, the Exclude Commute setting in Workspace Settings continues to display mi. The unit updates to km only after reopening the setting and saving the distance again.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7208112_1784036576536.Screenrecorder-2026-07-14-19-00-14-146.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7208112

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022077136486010260815
• Upwork Job ID: 2077136486010260815
• Last Price Increase: 2026-07-14

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/bef8b333de7a68d695b16b8d610c1d721f2d981f81610e637666164d83b75605

[ijmalik]

Proposal

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

After changing a workspace's distance unit from miles to kilometres, the "Exclude commute" row on the Distance rates settings page keeps displaying mi until the commute distance is re-saved, even though the exclusion editor itself already shows km.

What is the root cause of that problem?

In PolicyDistanceRatesSettingsPage.tsx (line 131), the "Exclude commute" row renders policy.commuterExclusions.fixedDistanceUnit ?? defaultUnit, preferring the unit snapshot stored in the commuterExclusions NVP at the time the exclusion was last saved over the workspace's live unit. SetPolicyCommuterExclusions doesn't even send the unit to the server (see setPolicyCommuterExclusions in src/libs/actions/Policy/DistanceRate.ts:584 — params are only policyID, commuterExclusionMethod, distance), and changing the unit via setPolicyDistanceRatesUnit (DistanceRate.ts:250) never touches commuterExclusions.fixedDistanceUnit, so the snapshot stays stale until a re-save refreshes it.

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

Treat the workspace's current custom-unit unit as the source of truth for display, exactly as PolicyCommuterExclusionsPage already does (it derives workspaceUnit from the custom unit's attributes.unit, which is why it shows km correctly). In PolicyDistanceRatesSettingsPage.tsx:131, swap the fallback precedence:

unit: defaultUnit ?? policy.commuterExclusions.fixedDistanceUnit ?? CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES,

This is consistent with the code's own documented ownership model — the comment above setPolicyCommuterExclusions states "the distance unit is owned by the workspace's distance custom unit". Because defaultUnit comes from Onyx and setPolicyDistanceRatesUnit updates it optimistically, the row updates immediately — including offline — the moment the unit is changed. The re-save flow (isSameUnit check in PolicyCommuterExclusionsPage.tsx:112) still refreshes the stored snapshot on the next save, so no other behavior changes.

What alternative solutions did you explore? (Optional)

Optimistically merging commuterExclusions: {fixedDistanceUnit: newUnit} inside setPolicyDistanceRatesUnit would also fix the display, but it duplicates state the custom unit already owns, needs matching failure-path rollback data, and would be silently reverted whenever the server echoes back the un-updated NVP — deriving the display from the live unit is simpler and can't drift.

[MelvinBot]

Proposal

What is the root cause of that problem?

The Exclude Commute summary on the Distance Rates settings page renders the unit that was stored on the exclusion when it was saved, not the workspace's current distance unit.

In PolicyDistanceRatesSettingsPage.tsx:131 the summary label is built with:

unit: policy.commuterExclusions.fixedDistanceUnit ?? defaultUnit ?? ...

fixedDistanceUnit is a snapshot written into commuterExclusions at save time (PolicyCommuterExclusionsPage.tsx:118, passing workspaceUnit). When the workspace unit is later changed, setPolicyDistanceRatesUnit only updates the custom unit's attributes.unit (defaultUnit) — it never touches commuterExclusions.fixedDistanceUnit. So the summary keeps showing the stale mi until the user reopens the exclusion page and re-saves, which rewrites fixedDistanceUnit to the new unit.

Note the Exclude Commute page itself already labels the input with the current workspace unit (PolicyCommuterExclusionsPage.tsx:63,75), which is why the two screens disagree until a re-save.

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

Display the current workspace unit in the summary instead of the stored snapshot — prefer defaultUnit over fixedDistanceUnit:

unit: defaultUnit ?? policy.commuterExclusions.fixedDistanceUnit ?? CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES

at PolicyDistanceRatesSettingsPage.tsx:131. This makes the summary consistent with the label already shown on the Exclude Commute page (which uses the live workspace unit), so the unit follows the workspace setting immediately without a re-save.

What alternative solutions did you explore? (Optional)

Alternatives considered

• Update fixedDistanceUnit when the workspace unit changes (in setPolicyDistanceRatesUnit): keeps the stored snapshot in sync, but requires deciding whether to also convert the stored fixedDistance value (mi→km). Since the Exclude Commute page keeps the same numeric value and only swaps the label, driving the display purely off defaultUnit is simpler and matches existing behavior. Confirm with design whether the numeric distance should be converted on unit change — if so, that conversion should also be reflected on the Exclude Commute page, not just the summary.
• Convert the value in both places: larger change; only pursue if product wants the underlying distance re-expressed in the new unit rather than kept as the same number relabeled.

---

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

[lorretheboy]

Proposal

What is the root cause of that problem?

commuterExclusions.fixedDistanceUnit is a client-side snapshot of the workspace distance unit taken at the moment the exclusion is saved, and nothing refreshes it afterwards.

The chain:

1. setPolicyCommuterExclusions writes fixedDistanceUnit into Onyx from whatever the workspace unit was at save time:

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

Lines 535 to 548 in 908aaf7

	function setPolicyCommuterExclusions(
	policyID: string,
	method: 'fixedDistance',
	fixedDistance: number,
	fixedDistanceUnit: string,
	previousCommuterExclusions: CommuterExclusions | undefined,
	) {
	const policyKey = `${ONYXKEYS.COLLECTION.POLICY}${policyID}` as const;
	const optimisticCommuterExclusions: CommuterExclusions = {
	method,
	fixedDistance,
	fixedDistanceUnit,
	};

It is never sent to the backend — the API only carries policyID, commuterExclusionMethod and distance, so the unit is not a server-side property of the exclusion at all:

App/src/libs/API/parameters/SetPolicyCommuterExclusionsParams.ts

Lines 1 to 11 in 908aaf7

	type SetPolicyCommuterExclusionsParams = {
	policyID: string;
	/**
	* Exclusion method - currently only "fixedDistance" is supported. R2 will add "homeAndOffice".
	* Named `commuterExclusionMethod` (not `method`) because the Web-Expensify WAF restricts the
	* plain `method` parameter to payment values.
	*/
	commuterExclusionMethod: string;
	/** Distance to exclude per claim. Must be > 0 when commuterExclusionMethod is "fixedDistance". */
	distance: number;
	};

2. Changing the unit goes through setPolicyDistanceRatesUnit, which only touches customUnits[...].attributes and never updates commuterExclusions:

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

Lines 250 to 264 in 908aaf7

	function setPolicyDistanceRatesUnit(policyID: string, currentCustomUnit: CustomUnit, newCustomUnit: CustomUnit) {
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.POLICY>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.POLICY}${policyID}`,
	value: {
	customUnits: {
	[newCustomUnit.customUnitID]: {
	...newCustomUnit,
	pendingFields: {attributes: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE},
	},
	},
	},
	},
	];

3. The settings summary prefers that stale snapshot over the live workspace unit, so it keeps rendering mi:

App/src/pages/workspace/distanceRates/PolicyDistanceRatesSettingsPage.tsx

Lines 127 to 134 in 908aaf7

	title={
	policy?.commuterExclusions?.method === CONST.POLICY.COMMUTER_EXCLUSION_METHOD.FIXED_DISTANCE && policy?.commuterExclusions?.fixedDistance != null
	? translate('workspace.distanceRates.commuterExclusions.summaryFixedDistance', {
	distance: policy.commuterExclusions.fixedDistance,
	unit: policy.commuterExclusions.fixedDistanceUnit ?? defaultUnit ?? CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES,
	})
	: translate('workspace.distanceRates.commuterExclusions.summaryDisabled')
	}

4. The Exclude Commute page reads the live unit from the custom unit instead, which is why it correctly shows km — the two screens disagree:

App/src/pages/workspace/distanceRates/PolicyCommuterExclusionsPage.tsx

Lines 55 to 63 in 908aaf7

	const [policyData] = useOnyx(`${ONYXKEYS.COLLECTION.POLICY}${policyID}`, {
	selector: (policy) => ({
	commuterExclusions: policy?.commuterExclusions,
	unit: getDistanceRateCustomUnit(policy)?.attributes?.unit,
	pendingFields: policy?.pendingFields,
	errorFields: policy?.errorFields,
	}),
	});
	const workspaceUnit = policyData?.unit ?? CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES;

5. Saving again re-runs setPolicyCommuterExclusions with the current workspaceUnit (the isSameUnit check exists precisely to force this write), refreshing the snapshot — that's why step 9 in the report "fixes" it.

So there are two sources of truth for one value, and the stale one wins on the settings screen. This is not a regression from #95483 — that PR only touched date-bound mileage rates.

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

Make the workspace distance unit the single source of truth for the summary, matching what the Exclude Commute page already does. In PolicyDistanceRatesSettingsPage, drop fixedDistanceUnit from the title and use the live defaultUnit (already derived from customUnit?.attributes?.unit on that page):

App/src/pages/workspace/distanceRates/PolicyDistanceRatesSettingsPage.tsx

Lines 127 to 134 in 908aaf7

	title={
	policy?.commuterExclusions?.method === CONST.POLICY.COMMUTER_EXCLUSION_METHOD.FIXED_DISTANCE && policy?.commuterExclusions?.fixedDistance != null
	? translate('workspace.distanceRates.commuterExclusions.summaryFixedDistance', {
	distance: policy.commuterExclusions.fixedDistance,
	unit: policy.commuterExclusions.fixedDistanceUnit ?? defaultUnit ?? CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES,
	})
	: translate('workspace.distanceRates.commuterExclusions.summaryDisabled')
	}

i.e. pass unit: defaultUnit ?? CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES. The summary then re-renders to km the instant the unit changes, with no extra write.

Since the field is client-only and no longer read anywhere, I'd also remove fixedDistanceUnit from the optimistic write in setPolicyCommuterExclusions and from the CommuterExclusions type:

App/src/types/onyx/Policy.ts

Lines 2154 to 2155 in 908aaf7

	/** Distance unit stored alongside fixedDistance ('mi' or 'km'). Mirrors the policy distance custom unit at the time it was set. */
	fixedDistanceUnit?: string;

and drop the now-pointless isSameUnit comparison in onSave, so a save with an unchanged distance no longer fires a redundant API call:

App/src/pages/workspace/distanceRates/PolicyCommuterExclusionsPage.tsx

Lines 111 to 118 in 908aaf7

	const isSameDistance = existingMethod === CONST.POLICY.COMMUTER_EXCLUSION_METHOD.FIXED_DISTANCE && existingCommuterExclusions?.fixedDistance === numeric;
	const isSameUnit = existingCommuterExclusions?.fixedDistanceUnit === workspaceUnit;
	if (isSameDistance && isSameUnit) {
	goBackToSettings();
	return;
	}
	setPolicyCommuterExclusions(policyID, CONST.POLICY.COMMUTER_EXCLUSION_METHOD.FIXED_DISTANCE, numeric, workspaceUnit, existingCommuterExclusions);

Note the stored number is not converted (10 mi becomes 10 km), which matches the backend's own behaviour since it never receives a unit.

What alternative solutions did you explore? (Optional)

Keep fixedDistanceUnit and refresh it inside setPolicyDistanceRatesUnit's optimistic data whenever the workspace unit changes. This works, but it keeps two copies of the same value in sync by hand and the copy is never persisted server-side, so it would go stale again on any other path that changes the unit.

[yusufdeveloper2903]

Proposal

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

After an admin changes the workspace distance unit (e.g. miles → kilometres), the Exclude commutes summary row on the Distance rates settings page keeps showing the old unit (mi). It only flips to km after the admin re-opens the Exclude commutes screen and re-saves the distance — even though nothing about the distance itself changed.

What is the root cause of that problem?

The summary row and the Exclude commutes screen read the unit from two different sources, and the summary reads a stale one.

The Exclude commutes summary renders the unit from the value persisted on the commuter-exclusion object, preferring fixedDistanceUnit over the live workspace unit — PolicyDistanceRatesSettingsPage.tsx:127-134:

unit: policy.commuterExclusions.fixedDistanceUnit ?? defaultUnit ?? CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES,

But fixedDistanceUnit is only a snapshot taken at save time — it is captured from the workspace unit when the exclusion is saved in PolicyCommuterExclusionsPage.tsx:112-118 and echoed into Onyx by setPolicyCommuterExclusions (DistanceRate.ts:544-548). Changing the workspace unit via setPolicyDistanceRatesUnit (DistanceRate.ts:250) never touches commuterExclusions.fixedDistanceUnit, so the snapshot goes stale and the summary keeps rendering mi.

The unit is not even a real property of the exclusion. The action's own comment is explicit — DistanceRate.ts:527-530:

the distance unit is owned by the workspace's distance custom unit … so we only echo it into Onyx optimistically.

Confirming this, setPolicyCommuterExclusions sends only distance to the backend — DistanceRate.ts:584 — never the unit. So fixedDistanceUnit is a redundant local echo whose only job is to be re-synced on the next save; between unit change and re-save it is stale.

The Exclude commutes screen itself does not have this bug precisely because it reads the live workspace unit, not the snapshot — PolicyCommuterExclusionsPage.tsx:63 derives workspaceUnit from the custom unit and :75 / :139 uses it for the input suffix. That is why step 6 shows km immediately while the settings summary in step 7 still shows mi.

This mechanism explains every detail: the summary is stale on unit change (settings page reads the snapshot), the exclusion screen is correct (reads live unit), and re-saving fixes it (re-writes the snapshot from the live unit). It is a pure JS/display bug in a shared .tsx — platform-independent; the Android App + Windows Chrome checkboxes just reflect where Applause happened to test, and iOS reproduces identically since the same shared file drives all platforms.

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

Primary fix (root cause): render the summary from the live workspace unit — the single source of truth — instead of the persisted snapshot. defaultUnit on this page is already customUnit?.attributes?.unit (PolicyDistanceRatesSettingsPage.tsx:59) — the same value the Exclude commutes screen uses as workspaceUnit. So we simply drop the stale fixedDistanceUnit preference in PolicyDistanceRatesSettingsPage.tsx:131:

title={
    policy?.commuterExclusions?.method === CONST.POLICY.COMMUTER_EXCLUSION_METHOD.FIXED_DISTANCE && policy?.commuterExclusions?.fixedDistance != null
        ? translate('workspace.distanceRates.commuterExclusions.summaryFixedDistance', {
              distance: policy.commuterExclusions.fixedDistance,
              unit: defaultUnit ?? CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES,
          })
        : translate('workspace.distanceRates.commuterExclusions.summaryDisabled')
}

This mirrors exactly what the Exclude commutes screen already does — one source of truth for the unit (the workspace custom unit), consistent across both screens. It is fully aligned with the design: the stored fixedDistance is a raw unit-agnostic number that is always shown against the current workspace unit (the exclusion screen re-labels the same number when the unit changes), so the summary should do the same.

Why this fixes it:

• Change unit mi → km (no re-save): defaultUnit is now km, summary immediately renders Exclude 5 km per claim. ✅
• Open exclusion screen after unit change: screen already showed km (live unit); now it matches the summary. ✅
• Re-save distance: setPolicyCommuterExclusions re-writes fixedDistanceUnit = km, but the summary no longer depends on it — display is identical before and after. ✅
• Offline unit change: defaultUnit reads the optimistic custom unit from Onyx, so the summary updates offline too. ✅

Falsifying the naive fix: the tempting one-liner is to patch setPolicyDistanceRatesUnit (DistanceRate.ts:250) to also rewrite commuterExclusions.fixedDistanceUnit on every unit change. That is the wrong layer: it keeps two copies of a value the code already declares is "owned by the workspace's distance custom unit" (DistanceRate.ts:527-530), forces every current and future unit-mutation path to remember to re-sync the snapshot, and adds an optimistic write for a field the backend never receives (DistanceRate.ts:584). Reading the live unit at display time removes the desync class entirely.

Regression safety: the change is confined to one presentational title expression on the settings page — the only place that preferred the snapshot. It does not alter what is saved, sent to the backend, or how the Exclude commutes screen behaves; it just makes the summary read the same live unit that screen already reads.

Result: the Exclude commutes summary shows the correct unit the instant the workspace distance unit changes, with no re-save required.

What alternative solutions did you explore? (Optional)

• Re-derive fixedDistanceUnit inside setPolicyDistanceRatesUnit on every unit change — rejected above: wrong layer, keeps a redundant second source of truth in sync forever, and writes a field the backend never persists (DistanceRate.ts:584). The display-layer fix eliminates the desync instead of chasing it.
• Stop persisting fixedDistanceUnit altogether (remove it from the optimistic echo in DistanceRate.ts:544-548 and its type) — larger blast radius touching the action, params and Onyx types for no user-visible gain once the summary reads the live unit. The primary fix makes the field harmlessly dormant; a follow-up cleanup can remove it separately if desired.
• Convert the stored distance number when the unit changes — rejected: the product treats fixedDistance as a raw unit-agnostic value (the exclusion screen re-labels the same number under the new unit, PolicyCommuterExclusionsPage.tsx:71 + :139), so converting would contradict the existing UX and is out of scope for this bug.

[melvin-bot]

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

[melvin-bot]

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

[ahmdshrif]

Proposal

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

After switching the workspace distance unit from miles to kilometres, the "Exclude commute" row in Distance rates → Settings keeps showing mi. The Exclude-commute page itself already shows the new unit, and the summary only corrects itself after the fixed distance is re-saved.

What is the root cause of that problem?

The structural cause is one fact with two owners: the distance unit is owned by the workspace's distance custom unit, but the summary row renders a stale save-time snapshot of it.

1. The code states the ownership explicitly — the unit "is owned by the workspace's distance custom unit (Auth resolves it server-side and snapshots it into the change log)"; commuterExclusions.fixedDistanceUnit is only an optimistic echo captured at save time:

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

   Lines 527 to 548 in 908aaf7

   	/**
   	* Set the commuter exclusion for a workspace. Currently only `fixedDistance` is supported; the
   	* distance unit is owned by the workspace's distance custom unit (Auth resolves it server-side and
   	* snapshots it into the change log), so we only echo it into Onyx optimistically.
   	*
   	* Callers should pass the workspace's current `commuterExclusions` so the failure path can restore
   	* the prior state.
   	*/
   	function setPolicyCommuterExclusions(
   	policyID: string,
   	method: 'fixedDistance',
   	fixedDistance: number,
   	fixedDistanceUnit: string,
   	previousCommuterExclusions: CommuterExclusions | undefined,
   	) {
   	const policyKey = `${ONYXKEYS.COLLECTION.POLICY}${policyID}` as const;
   	const optimisticCommuterExclusions: CommuterExclusions = {
   	method,
   	fixedDistance,
   	fixedDistanceUnit,
   	};

   . The API command doesn't even send a unit:

   App/src/libs/API/parameters/SetPolicyCommuterExclusionsParams.ts

   Lines 1 to 13 in 908aaf7

   	type SetPolicyCommuterExclusionsParams = {
   	policyID: string;
   	/**
   	* Exclusion method - currently only "fixedDistance" is supported. R2 will add "homeAndOffice".
   	* Named `commuterExclusionMethod` (not `method`) because the Web-Expensify WAF restricts the
   	* plain `method` parameter to payment values.
   	*/
   	commuterExclusionMethod: string;
   	/** Distance to exclude per claim. Must be > 0 when commuterExclusionMethod is "fixedDistance". */
   	distance: number;
   	};
   	export default SetPolicyCommuterExclusionsParams;

2. The Settings summary prefers the snapshot over the live unit — policy.commuterExclusions.fixedDistanceUnit ?? defaultUnit:

   App/src/pages/workspace/distanceRates/PolicyDistanceRatesSettingsPage.tsx

   Lines 127 to 134 in 908aaf7

   	title={
   	policy?.commuterExclusions?.method === CONST.POLICY.COMMUTER_EXCLUSION_METHOD.FIXED_DISTANCE && policy?.commuterExclusions?.fixedDistance != null
   	? translate('workspace.distanceRates.commuterExclusions.summaryFixedDistance', {
   	distance: policy.commuterExclusions.fixedDistance,
   	unit: policy.commuterExclusions.fixedDistanceUnit ?? defaultUnit ?? CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES,
   	})
   	: translate('workspace.distanceRates.commuterExclusions.summaryDisabled')
   	}

3. Nothing updates the snapshot when the unit changes: setPolicyDistanceRatesUnit writes only the custom unit, never commuterExclusions:

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

   Line 250 in 908aaf7

   function setPolicyDistanceRatesUnit(policyID: string, currentCustomUnit: CustomUnit, newCustomUnit: CustomUnit) {

4. Re-saving "fixes" it because the exclusion page detects the unit mismatch (isSameUnit) and re-calls setPolicyCommuterExclusions with the live unit, re-stamping the snapshot:

   App/src/pages/workspace/distanceRates/PolicyCommuterExclusionsPage.tsx

   Lines 111 to 118 in 908aaf7

   	const isSameDistance = existingMethod === CONST.POLICY.COMMUTER_EXCLUSION_METHOD.FIXED_DISTANCE && existingCommuterExclusions?.fixedDistance === numeric;
   	const isSameUnit = existingCommuterExclusions?.fixedDistanceUnit === workspaceUnit;
   	if (isSameDistance && isSameUnit) {
   	goBackToSettings();
   	return;
   	}
   	setPolicyCommuterExclusions(policyID, CONST.POLICY.COMMUTER_EXCLUSION_METHOD.FIXED_DISTANCE, numeric, workspaceUnit, existingCommuterExclusions);

5. This is the leftover half of #94267. That issue's fix, PR #94457, touched only PolicyCommuterExclusionsPage.tsx (which now reads the live unit for its suffix:

   App/src/pages/workspace/distanceRates/PolicyCommuterExclusionsPage.tsx

   Lines 55 to 75 in 908aaf7

   	const [policyData] = useOnyx(`${ONYXKEYS.COLLECTION.POLICY}${policyID}`, {
   	selector: (policy) => ({
   	commuterExclusions: policy?.commuterExclusions,
   	unit: getDistanceRateCustomUnit(policy)?.attributes?.unit,
   	pendingFields: policy?.pendingFields,
   	errorFields: policy?.errorFields,
   	}),
   	});
   	const workspaceUnit = policyData?.unit ?? CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES;
   	const existingCommuterExclusions = policyData?.commuterExclusions;
   	const existingMethod = existingCommuterExclusions?.method;
   	const [selectedKey, setSelectedKey] = useState<ExclusionOptionKey>(
   	existingMethod === CONST.POLICY.COMMUTER_EXCLUSION_METHOD.FIXED_DISTANCE ? CONST.POLICY.COMMUTER_EXCLUSION_METHOD.FIXED_DISTANCE : CONST.POLICY.COMMUTER_EXCLUSION_TYPE.DISABLED,
   	);
   	const [fixedDistanceInput, setFixedDistanceInput] = useState<string>(() => (existingCommuterExclusions?.fixedDistance != null ? String(existingCommuterExclusions.fixedDistance) : ''));
   	const [inlineError, setInlineError] = useState<string>('');
   	// Lowercased to match design copy ("miles" / "kilometers"); the existing translation keys are already lowercase.
   	const unitLabel = translate(getUnitTranslationKey(workspaceUnit));

   ) and never touched the Settings summary, which was introduced with the feature in PR #92496.

This chain explains every repro detail: steps 5/7 (summary reads the stale mi snapshot), step 6 (exclusion page reads the live unit — the #94457 fix), steps 8–9 (re-save re-stamps the snapshot), and why it reproduces identically on Android app and Windows Chrome (shared code, no platform split exists under src/pages/workspace/distanceRates/).

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

Flip the preference on the one line so the summary reads the live workspace unit, keeping the snapshot only as a hydration fallback — in PolicyDistanceRatesSettingsPage.tsx (L131):

unit: defaultUnit ?? policy.commuterExclusions.fixedDistanceUnit ?? CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES,

defaultUnit is customUnit?.attributes?.unit (L59) — the exact value the Unit row directly above already renders, so the two rows can never disagree again, and the fix works instantly for policies whose persisted snapshot is already stale, online or offline. Regression safety in one sentence: no other consumer's behavior changes — isSameUnit (which forces a re-save API call when only the unit changed, keeping the server-side change-log snapshot fresh), the optimistic echo in setPolicyCommuterExclusions, and the change-log renderer (which correctly reads the historical unit from originalMessage:

App/src/libs/ReportActionsUtils.ts

Lines 4230 to 4256 in 908aaf7

	function getUpdatedCommuterExclusionsMessage(translate: LocalizedTranslate, reportAction: OnyxEntry<ReportAction>) {
	if (!isActionOfType(reportAction, CONST.REPORT.ACTIONS.TYPE.POLICY_CHANGE_LOG.UPDATE_COMMUTER_EXCLUSIONS)) {
	return getReportActionText(reportAction);
	}
	const originalMessage = getOriginalMessage(reportAction);
	const updatedField = originalMessage?.updatedField;
	if (updatedField === CONST.POLICY.COMMUTER_EXCLUSION_TYPE.METHOD) {
	const newMethod = originalMessage?.newValue;
	if (newMethod === CONST.POLICY.COMMUTER_EXCLUSION_METHOD.FIXED_DISTANCE) {
	return translate('workspaceActions.commuterExclusions.changedToFixedDistance');
	}
	}
	if (updatedField === CONST.POLICY.COMMUTER_EXCLUSION_TYPE.FIXED_DISTANCE) {
	const newValue = typeof originalMessage?.newValue === 'number' ? originalMessage.newValue : Number(originalMessage?.newValue ?? 0);
	const unit = originalMessage?.unit ?? CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES;
	if (originalMessage?.oldValue == null) {
	return translate('workspaceActions.commuterExclusions.setFixedDistance', {distance: newValue, unit});
	}
	const oldValue = typeof originalMessage.oldValue === 'number' ? originalMessage.oldValue : Number(originalMessage.oldValue);
	return translate('workspaceActions.commuterExclusions.changedFixedDistance', {newDistance: newValue, oldDistance: oldValue, unit});
	}
	if (updatedField === CONST.POLICY.COMMUTER_EXCLUSION_TYPE.DISABLED) {

) all stay exactly as they are.

Why the obvious spot-fix does NOT work: the tempting patch is to update commuterExclusions.fixedDistanceUnit inside setPolicyDistanceRatesUnit's optimisticData when the unit changes. Two mechanisms defeat it: (1) the server owns that policy field and UpdatePolicyDistanceUnit doesn't modify it server-side, so the next full policy push (OpenApp/reconnect) overwrites the optimistic patch with the stored mi and the bug silently returns; (2) every existing policy already has a stale persisted snapshot — a fix-on-transition only helps future unit changes, so the summary stays wrong for all previously-saved exclusions until a manual re-save. Reading the live unit removes the dependency on snapshot freshness entirely instead of trying to keep two copies in sync.

What alternative solutions did you explore? (Optional)

1. Update the snapshot in setPolicyDistanceRatesUnit — rejected per the mechanisms above (server sync reverts it; stale existing data stays stale), and making it durable would need a backend change.
2. Remove fixedDistanceUnit from Onyx and the Policy type entirely — cleaner long-term, but it touches the writer, the isSameUnit re-stamp logic (still needed so the change log records unit changes), and the type, for the same user-visible result; not worth the extra surface.
3. Convert the stored number on unit change (10 mi → 16.1 km) — not the product behavior: the number is unit-agnostic ("distance per claim in the workspace unit"); both the exclusion page and the re-save path keep the number and swap the unit.