[$250] Expense-Unexpected error on creating distance expense when Exclude a distance per claim is set

[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-2
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+usimha@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: Money Requests

Action Performed:

1. Launch app
2. Login expensifail account
3. Go to workspace settings - distance rate - settings - Exclude commute - Exclude a fixed distance per claim - enter an distance & save
4. Open workspace chat
5. Create a manual distance expense

Expected Result:

Unexpected error must not be shown on creating distance expense when Exclude a distance per claim is set.

Actual Result:

Unexpected error on creating distance expense when Exclude a distance per claim is set.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7208294_1784048469852.Screenrecorder-2026-07-14-22-19-09-710.1.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022077144059571613950
• Upwork Job ID: 2077144059571613950
• 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/73184d4c2ca14c7e0b86738bc4891778e13e54b4ce2ea785e01bde18e59379c4

[ijmalik]

Proposal

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

After enabling "Exclude a fixed distance per claim" in the workspace's distance-rate commuter exclusion settings, creating a manual distance expense fails and shows "Unexpected error submitting this expense. Please try again later."

What is the root cause of that problem?

The error message is iou.error.genericCreateFailureMessage, which is only applied via failureData when the CreateDistanceRequest API call itself fails — and the App sends an identical payload whether or not commuter exclusions are configured, since createDistanceRequest in src/libs/actions/IOU/Split.ts (and the whole expense-creation path) never reads policy.commuterExclusions; that NVP is only written by setPolicyCommuterExclusions in src/libs/actions/Policy/DistanceRate.ts. Therefore the failure originates in Auth's CreateDistanceRequest command, which errors while applying the fixed-distance exclusion to a manual (waypoint-less, user-typed distance) expense — e.g., the exclusion handler not supporting the distance param path, or producing a non-positive adjusted amount. This is a backend regression from the recently shipped commuter exclusions feature (PR #92496 and follow-ups), so the primary fix is internal.

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

The primary fix is in Auth: CreateDistanceRequest must apply the fixed-distance exclusion correctly for manual distance expenses (subtract the configured fixedDistance from the submitted distance, clamping the adjusted distance at 0 rather than throwing). On the App side, we should mirror that logic in the optimistic data so the amount the user sees matches what the server will store: in getDistanceRequestAmount (src/libs/DistanceRequestUtils.ts), accept the policy's commuterExclusions and compute the amount from Math.max(distance - fixedDistance, 0) when method === CONST.POLICY.COMMUTER_EXCLUSION_METHOD.FIXED_DISTANCE, converting units if fixedDistanceUnit differs from the rate's unit. The confirmation page and createDistanceRequest then show/store an amount consistent with the backend's post-exclusion amount, avoiding a flicker/correction after the server responds. Note the same optimistic-amount gap exists for all three distance entry points (map/waypoints, manual, odometer) since they all funnel through getDistanceRequestAmount, so the change covers them uniformly.

What alternative solutions did you explore? (Optional)

I considered a pure App-side fix (blocking submission or pre-adjusting the amount client-side), but since the failure is the API call itself rejecting — reproducible in production with an unchanged client payload — no client-only change can fully resolve the error; the exclusion math must be fixed where it's enforced, in Auth.

[abbasifaizan70]

@ijmalik Thanks for propsoal. But you can not post proposal until you see Help wanted tag. Thanks. Please check contribution guidelines.

[MelvinBot]

Issue Analysis

⚠️ Confidence: Medium — based on App code evidence; I could not reach production logs in this run to confirm the exact backend error (queries to run are listed below).

Root Cause: This is a backend regression, not an App bug. The "Unexpected error" is the App's generic failure message iou.error.genericCreateFailureMessage ("Unexpected error submitting this expense. Please try again later."), which the App writes onto the transaction only when the CreateDistanceRequest API call comes back with a non-200 response. The commute-exclusion subtraction ("Exclude a fixed distance per claim") is applied entirely server-side, so when it errors on a manual distance expense the App just surfaces the generic error.

The App does not read, compute, or send the commute/fixed-distance value anywhere in the distance-expense creation flow — a grep across the IOU create actions, DistanceRequestUtils, and TransactionUtils finds zero commute references. Manual amount is a plain distance × rate (DistanceRequestUtils.getDistanceRequestAmount), and the CreateDistanceRequest params carry no commute field. The backend derives and subtracts the excluded fixed distance from the policy setting — and that new code path (added alongside #95483) is what fails for a manually-created distance expense.

Recommended Fix: The fix requires changes outside the App repo (the backend handler for the distance-request command / commuter-exclusion logic). An internal engineer with access to that repository should investigate why applying the fixed-distance commute exclusion to a manual distance expense produces a non-200 response — a likely candidate is the subtraction producing an invalid/negative/zero distance for a manual expense that has no computed route. Please escalate to an internal engineer; there is no App-side code change to make here.

Investigation details

Symptoms: Enable a distance rate's commute exclusion (Settings → Distance rate → Settings → Exclude commute → "Exclude a fixed distance per claim", enter a distance, save), then create a manual distance expense in the workspace chat → "Unexpected error". Reproducible in production and staging (V9.4.34-2), Android + Windows Chrome.

Evidence chain:

1. Admin enables the exclusion → App sends only policyID, method, and distance to the backend; the backend stores it and resolves the unit server-side.
2. User creates a manual distance expense → App computes amount = distance × rate with no commute subtraction and sends CreateDistanceRequest (params: amount, distance, customUnitRateID, waypoints, … — no commute field).
3. Backend applies the commuter-exclusion subtraction → returns non-200.
4. App applies its failureData, tagging the transaction with iou.error.genericCreateFailureMessage → user sees "Unexpected error".

Why it's backend, not App: the App has no commute logic on the create path, sends no commute parameters, and only reflects the backend's non-200 as a generic error. So the fix cannot live in App.

Log queries to confirm (I couldn't run them this session):

• {type=web} email:="Applausetester+usimha@applause.expensifail.com" "CreateDistanceRequest" — fastest path to the failing requestID + error.
• {type=web} "CreateDistanceRequest" ("error" OR "exception" OR "jsonCode")
• Backend logs for commuter-exclusion / fixed-distance handling around the failing request.

Open question: Does this fail only for manual distance expenses (vs. mapped/GPS)? That would narrow it to how the backend subtracts the fixed commute distance from an expense with no computed route.

---

This looks like a backend/internal issue, so the next step is escalation to an internal engineer rather than an App PR. Reply with @MelvinBot <your feedback> to refine this analysis.

[yusufdeveloper2903]

Proposal

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

When a workspace's distance rate has Exclude commute → Exclude a fixed distance per claim enabled, creating a manual distance expense on that workspace fails and surfaces the red‑brick‑road error "Unexpected error submitting this expense. Please try again later." instead of creating the expense.

What is the root cause of that problem?

The App never accounts for the commuter fixed‑distance exclusion anywhere in the distance‑expense creation path — the exclusion is a policy NVP that is written and applied entirely server‑side, and the "Unexpected error" is the App's own optimistic failure message that only shows when the backend rejects the create command.

Tracing the code confirms each link:

• The exclusion is stored on the policy by setPolicyCommuterExclusions → SetPolicyCommuterExclusionsParams: the App sends only {policyID, commuterExclusionMethod, distance} and writes policy.commuterExclusions (typed at Policy.ts:2147-2155). The distance unit is resolved by Auth — the frontend owns none of the exclusion math.
• When a manual distance expense is created, the amount is computed by getDistanceRequestAmount → roundDistanceAmount, which is purely Math.round(distance * rate) — it never reads commuterExclusions/fixedDistance. Grepping DistanceRequestUtils.ts and MoneyRequestBuilder.ts for commuterExclusions returns zero hits.
• The create command itself carries no exclusion data: CreateDistanceRequestParams has waypoints, customUnitRateID, distance, amount, odometerStart/End, gpsCoordinates, distanceRequestType — but no commuterExclusions/fixedDistance field.
• The exact "Unexpected error" string is iou.error.genericCreateFailureMessage (en.ts:1589). The App only ever plants it in the optimistic failureData: for a receipt‑less manual request via getReceiptError (isEmptyObject(receipt) || !isScanRequest → generic key), and on the created report actions at MoneyRequestBuilder.ts:1043 and :1094. This message is failureData — it is applied only when the CreateDistanceRequest command comes back rejected.

Putting it together: the App optimistically builds the transaction with the full, un‑excluded distance * rate amount and sends CreateDistanceRequest. The fixed‑distance exclusion is applied by Auth, and Auth rejects the command when it applies that exclusion to a manually‑entered (waypoint‑less) distance — so the optimistic failureData fires and the user sees the generic "Unexpected error." This explains every symptom detail: it reproduces on staging and production and on both listed platforms (Android App, Windows Chrome), because the trigger is a server‑side policy NVP + backend command, not any platform‑specific client code — the App behaves identically on every platform and simply surfaces the backend rejection.

History of how we got here: the commuter‑exclusions feature (settings UI in PolicyCommuterExclusionsPage.tsx + setPolicyCommuterExclusions, behind the COMMUTER_EXCLUSIONS beta) shipped the admin configuration surface, but the money‑request builder and DistanceRequestUtils were never taught about the exclusion — the reduction is left to Auth. The manual‑distance path (no waypoints/route) is the case Auth's exclusion computation does not handle cleanly, so it rejects and the App falls back to the generic create‑failure message.

Confidence: medium (App side is certain, backend rejection reason is inferred). Everything in the App repo is confirmed at the pinned commit: the App neither computes nor sends the exclusion, and "Unexpected error" is strictly the optimistic create‑failure fallback. The one link that needs a log to nail down is the exact reason Auth rejects CreateDistanceRequest for a manual distance under an active exclusion. What would confirm it: the CreateDistanceRequest API response (jsonCode + message) captured while reproducing — a non‑200 with no per‑field message is exactly what leaves the generic optimistic error on screen.

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

Primary fix (root cause): The exclusion is computed and enforced entirely in Auth, so the create‑time rejection must be fixed there — Auth's CreateDistanceRequest handler should apply the fixed‑distance commuter exclusion to manual/odometer distance expenses the same way it does for mapped‑waypoint routes, rather than rejecting them. The App sends distance + customUnitRateID correctly; there is nothing in Expensify/App that produces or can suppress a valid‑input rejection, because the App does not model the exclusion at all (confirmed: 0 references in the create/compute path).

Additional fix (App‑side hardening, so a doomed claim never shows the generic error): mirror the validation guard the manual step already runs. Today submitAndNavigateToNextPage blocks non‑positive and over‑limit distances with a specific inline message:

if (!value.length || parseFloat(value) <= 0) {
    setFormError(translate('iou.error.invalidDistance'));
    return;
}

We can extend the same guard so that, when policy.commuterExclusions?.method === 'fixedDistance', a claim whose net billable distance after the exclusion is ≤ 0 is blocked with a specific, actionable inline error (e.g. "Distance must be greater than the excluded commute distance") before the doomed CreateDistanceRequest is sent — instead of the vague "Unexpected error." This reuses the existing commuterExclusions.fixedDistance/fixedDistanceUnit already on the policy and the existing convertDistanceUnit helper, and mirrors the precedent set by invalidDistance/distanceAmountTooLargeReduceDistance.

Why this fixes it:

• Auth applies exclusion to manual distance → command accepted: the primary fix removes the rejection, so the optimistic failureData (genericCreateFailureMessage) is never applied and the expense is created.
• Distance below the exclusion → specific inline error, no doomed request: the App‑side guard catches it locally and tells the user exactly what's wrong, so the generic "Unexpected error" is never surfaced for this case either.

Neither change touches the amount math for expenses on policies without an exclusion — the guard is behind commuterExclusions?.method === 'fixedDistance' and the create path is otherwise unchanged, so there is no regression to standard distance expenses.

Result: Creating a manual distance expense on a workspace with "Exclude a fixed distance per claim" set succeeds normally, and any genuinely invalid claim shows a precise inline message instead of "Unexpected error submitting this expense."

What alternative solutions did you explore? (Optional)

• "It's a frontend crash / the rate lookup returns undefined." Killed: getDistanceRequestAmount is pure distance * rate (DistanceRequestUtils.ts:307-322) and downstream consumers guard rate with ?? 0, so a missing rate degrades to amount 0, not a thrown "Unexpected error." The message is failureData, not a computed/throw path.
• "PR Remove dateBoundMileageRate beta #95483 (removing the dateBoundMileageRate beta) caused it." Killed: that PR only removed beta gates on the distance‑rate CRUD UI (CreateDistanceRatePage, date edit/details pages); it did not touch CreateDistanceRequestParams, getMoneyRequestInformation, or any exclusion logic. It's the standard BrowserStack test source for the regression run, not the mechanism.
• "Just subtract the fixed distance in the App's optimistic amount so it matches the server." Wrong layer: the optimistic amount is only a preview — Auth recomputes the authoritative amount on success. Aligning the preview does not stop Auth from rejecting the create command, so it would not remove the "Unexpected error." The rejection has to be fixed where the exclusion is enforced (Auth), which is why that is the primary fix.

[ahmdshrif]

Proposal

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

When a workspace has "Exclude a fixed distance per claim" (commuterExclusions, method fixedDistance) enabled, creating a distance expense throws an unexpected error instead of producing a valid expense.

What is the root cause of that problem?

The commuter-exclusion setting introduced for distance rates is currently consumed by the client only in the policy settings UI and in report-action change logs — it is never applied in the amount/quantity computation used when creating a distance expense. The billable amount is computed purely from raw distance × rate:

• App/src/libs/DistanceRequestUtils.ts

  Lines 320 to 322 in 0032e48

  	function getDistanceRequestAmount(distance: number, unit: Unit, rate: number): number {
  	return roundDistanceAmount(convertDistanceUnit(distance, unit), rate);
  	}

• App/src/libs/TransactionUtils/index.ts

  Lines 840 to 842 in 0032e48

  	const distanceInMeters = getDistanceInMeters(updatedTransaction, unit);
  	let amount = DistanceRequestUtils.getDistanceRequestAmount(distanceInMeters, unit, rate ?? 0);
  	amount = isFromExpenseReport || isUnReportedExpense ? -amount : amount;

Because the client builds the optimistic transaction without subtracting commuterExclusions.fixedDistance, its state diverges from the server (which does apply the exclusion). For a trip whose distance ≤ the fixed exclusion the net billable distance/amount becomes ≤ 0, and this un-guarded case surfaces as the unexpected error.

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

Apply the policy exclusion when computing the distance-expense amount, and clamp so the net can never go negative. In getDistanceRequestAmount (or its callers in TransactionUtils), subtract the converted fixedDistance before multiplying by the rate:

const excluded = getFixedDistanceExclusion(policy, unit); // 0 if method !== fixedDistance
const billable = Math.max(convertDistanceUnit(distance, unit) - excluded, 0);
return roundDistanceAmount(billable, rate);

This keeps the optimistic amount consistent with the server and avoids the ≤ 0 path.
Regression: verify normal distance expenses (no exclusion set) are unchanged and a trip shorter than the exclusion creates a $0 expense rather than erroring.

[lorretheboy]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-14 21:40:31 UTC.

Proposal

What is the root cause of that problem?

commuterExclusions is written to the policy and read back only by its own settings page and the change log. Nothing in the distance-expense path consults it.

To be precise about why — correcting my earlier comment on this issue: it is not a plumbing problem. usePolicyForTransaction returns the raw Onyx policy with no field filtering, so policy.commuterExclusions is already sitting in scope at every distance entry point:

App/src/hooks/usePolicyForTransaction.ts

Lines 38 to 52 in 0032e48

	function usePolicyForTransaction({transaction, reportPolicyID, action, iouType, policyDraft, isPerDiemRequest}: UsePolicyForTransactionParams): UsePolicyForTransactionResult {
	const {policyForMovingExpenses} = usePolicyForMovingExpenses();
	const customUnitID = transaction?.comment?.customUnit?.customUnitID;
	const [customUnitPolicy] = useOnyx(ONYXKEYS.COLLECTION.POLICY, {selector: (policies) => getPolicyByCustomUnitID(transaction, policies)}, [customUnitID]);
	const [reportPolicy] = useOnyx(`${ONYXKEYS.COLLECTION.POLICY}${reportPolicyID}`);
	const isUnreportedExpense = isExpenseUnreported(transaction);
	const isCreatingTrackExpense = action === CONST.IOU.ACTION.CREATE && iouType === CONST.IOU.TYPE.TRACK;
	const policyForSelfDMExpense = isPerDiemRequest ? customUnitPolicy : policyForMovingExpenses;
	const policy = isUnreportedExpense || isCreatingTrackExpense ? policyForSelfDMExpense : (reportPolicy ?? policyDraft);
	return {policy};

The gap is purely that the amount math never asks for it. getDistanceRequestAmount is distance × rate and nothing else:

App/src/libs/DistanceRequestUtils.ts

Lines 320 to 322 in 0032e48

	function getDistanceRequestAmount(distance: number, unit: Unit, rate: number): number {
	return roundDistanceAmount(convertDistanceUnit(distance, unit), rate);
	}

So the chain is: the client builds the optimistic transaction and the CreateDistanceRequest params from the full, un-excluded distance → Auth applies billable = distance − fixedDistance and rejects when that lands at or below zero, which is exactly the tester's setup (a small manual trip against a fixed exclusion) → the client has no handling for it, so it falls into the catch-all that stamps every non-scan create failure with iou.error.genericCreateFailureMessage:

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

Lines 339 to 340 in 0032e48

	return isEmptyObject(receipt) || !isScanRequest
	? getMicroSecondOnyxErrorWithTranslationKey('iou.error.genericCreateFailureMessage', errorKey)

That translates to "Unexpected error submitting this expense. Please try again later." — the reported symptom. The App is relaying a server rejection it never gave itself a chance to prevent.

Who owns the unit (this matters for the fix). The client never sends a unit — Auth resolves it from the workspace's distance custom unit, and fixedDistanceUnit in Onyx is only an optimistic echo of the workspace unit at set-time:

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

Lines 527 to 530 in 0032e48

	/**
	* 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.

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

Lines 1 to 11 in 0032e48

	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;
	};

So fixedDistance is authoritatively expressed in the workspace's current unit. Any client code that converts from the stored snapshot will disagree with Auth the moment an admin flips the workspace unit after setting the exclusion.

The settings page only guards that the number is a positive integer under 19000. It cannot know future trip lengths, so it can't catch this at set-time.

(PR #95483 only removed the dateBoundMileageRate beta gate and is a no-op for beta-enabled users — it isn't the cause. This is a gap in the newer commuterExclusions feature.)

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

No plumbing is needed — the policy is already in scope. Teach the one place distance becomes a billable amount about the exclusion.

1. Add a shared helper in DistanceRequestUtils next to the existing amount math that returns the billable distance:

App/src/libs/DistanceRequestUtils.ts

Lines 320 to 322 in 0032e48

	function getDistanceRequestAmount(distance: number, unit: Unit, rate: number): number {
	return roundDistanceAmount(convertDistanceUnit(distance, unit), rate);
	}

Roughly getBillableDistance(distance, unit, policy) → Math.max(0, distance - fixedDistance) when method === 'fixedDistance'. Deliberately no unit conversion — fixedDistance is already in the workspace unit, which is the same unit the rate resolves to, so converting the stored fixedDistanceUnit snapshot would introduce the exact server/client drift we're trying to remove.

2. Scope it to workspace rates. P2P and placeholder rates have no policy exclusion, and there's already a predicate for that — gate on it so personal distance expenses are provably untouched:

App/src/libs/DistanceRequestUtils.ts

Lines 341 to 347 in 0032e48

	function isUnsetDistanceCustomUnitRateID(customUnitRateID: string | undefined): boolean {
	if (!customUnitRateID) {
	return true;
	}
	return customUnitRateID === CONST.CUSTOM_UNITS.FAKE_P2P_ID || customUnitRateID === CONST.CUSTOM_UNITS.UNSET_DISTANCE_RATE_ID;
	}

3. Block submission with a real, actionable message when the trip distance is at or below the exclusion, alongside the existing limit check. Keeping the guard in the util means the map and odometer entry points get it too:

App/src/pages/iou/request/step/IOURequestStepDistanceManual.tsx

Lines 302 to 318 in 0032e48

	const submitAndNavigateToNextPage = () => {
	const value = numberFormRef.current?.getNumber() ?? '';
	if (!value.length || parseFloat(value) <= 0) {
	setFormError(translate('iou.error.invalidDistance'));
	return;
	}
	// Validation: Check that distance * rate doesn't exceed the backend's safe amount limit
	if (!DistanceRequestUtils.isDistanceAmountWithinLimit(parseFloat(value), rate)) {
	setFormError(translate('iou.error.distanceAmountTooLargeReduceDistance'));
	return;
	}
	suppressDiscardPrompt();
	navigateToNextPage(value);
	};

4. Route getTaxableAmount through the same billable base — it derives tax from the distance amount, so leaving it on the raw distance would over-report tax on every excluded claim:

App/src/libs/DistanceRequestUtils.ts

Lines 515 to 526 in 0032e48

	function getTaxableAmount(policy: OnyxEntry<Policy>, customUnitRateID: string, distance: number) {
	const distanceUnit = getDistanceRateCustomUnit(policy);
	const customUnitRate = getDistanceRateCustomUnitRate(policy, customUnitRateID);
	if (!distanceUnit?.customUnitID || !customUnitRate) {
	return 0;
	}
	const unit = distanceUnit?.attributes?.unit ?? CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES;
	const rate = customUnitRate?.rate ?? CONST.DEFAULT_NUMBER_ID;
	const amount = getDistanceRequestAmount(distance, unit, rate);
	const taxClaimablePercentage = customUnitRate.attributes?.taxClaimablePercentage ?? CONST.DEFAULT_NUMBER_ID;
	return amount * taxClaimablePercentage;
	}

Other call sites needing the same treatment: IOURequestStepDistanceMap.tsx, IOURequestStepDistanceOdometer.tsx, and the confirmation list's distance amount display.

Regression check: with no exclusion set the helper returns the distance unchanged, so standard and P2P distance expenses are byte-identical.

What alternative solutions did you explore? (Optional)

• Plumb commuterExclusions through the IOU policy selector first. I originally proposed this; it's unnecessary. That selector has a single consumer — IOURequestStartPage — and does not feed the amount math, so the change would have been a no-op.
• Convert fixedDistance from the stored fixedDistanceUnit. Also mine originally, and wrong: Auth resolves the unit from the workspace custom unit and the client never sends one, so converting the snapshot re-creates the drift after a unit change. For the same reason, adding fixedDistanceUnit to the wire params would fight the feature's design rather than fix it.
• Guard only, leave the amount math alone. Smaller and it kills the reported symptom, but the confirmation page would still show a pre-exclusion amount that jumps once Auth responds — and tax would stay wrong. I'd prefer the full fix.
• Bake the subtraction into getDistanceRequestAmount itself. Tempting, but that function is also called from edit/recompute paths for existing transactions and from P2P flows; a single unconditional subtraction there is how you get silent $0 expenses and hard-to-trace drift. A separate, explicitly-scoped helper keeps the blast radius visible.

[melvin-bot]

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