[Due for payment 2026-08-19] [$250] Web - Distance - Unexpected error after editing the rate and going back online

[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: undefined
Reproducible in staging?: Yes
Reproducible in production?: undefined
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://github.com/Expensify/Expensify/issues/427003
Email or phone of affected tester (no customers): undefined
Issue reported by: Applause Internal Team
Bug source: undefined
Device used: undefined
App Component: undefined

Action Performed:

Pre-requisite: have a workspace with multiple distance rates.

1. Go to a workspace chat.
2. Submit a distance expense.
3. Go to the transaction thread.
4. Go offline
5. Click "Rate"
6. Select a different rate.
7. Verify the distance unit in the system message uses the short version: "mi" or "km" after changing the distance rate.
8. Go online
9. Verify the system message does not change.

Expected Result:

7. Verify the distance unit in the system message uses the short version: "mi" or "km" after changing the distance rate.
   No error after going online

Actual Result:

No system message when editing the rate offline, and an unexpected error after editing the rate and going back online

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7181923_1781584713906.427003.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022077472104257624250
• Upwork Job ID: 2077472104257624250
• Last Price Increase: 2026-07-22

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

⚠️ Medium confidence — the code path is well understood, but the exact offline trigger should be confirmed with a live repro (see "Needs verification" below).

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

Changing the distance rate of an already-submitted distance expense while offline produces two problems: (1) no MODIFIED_EXPENSE system message appears in the transaction thread, and (2) after reconnecting, an unexpected error (RBR) is stamped on the transaction.

What is the root cause of that problem?

Both symptoms come from the offline optimistic path in updateMoneyRequestDistanceRate → getUpdateMoneyRequestParams.

(1) No system message offline. The optimistic MODIFIED_EXPENSE for a rate change is driven entirely by the merchant/amount that getUpdatedTransaction recomputes locally. For a rate-only edit that recompute depends on getDistanceInMeters(...) returning a real distance and getRate(...) resolving unit/rate/currency for the newly-selected rate. When any of these is missing offline, getDistanceMerchant returns "Pending…" or "" (no @). A merchant without @ fails the .includes('@') guard, so ModifiedExpenseMessage skips the distance branch and no readable "changed the rate to … mi/km" line is produced.

(2) Error after reconnect. For distance transactions the failure handler intentionally does not attach the error to the report action (isDistanceTransaction ? null : …) — the comment says "the error will be handled by API response for distance requests." So when the UpdateMoneyRequestDistanceRate command is sent on reconnect and the backend rejects it, the generic failureData fires and sets transaction.errorFields = iou.error.genericEditFailureMessage, which surfaces as the RBR "unexpected error."

Evidence (Expensify/App @ 763218c)

• Optimistic action gating & the distance-specific "no error on the action" branch: UpdateMoneyRequest.ts:1672-1735 — note !(hasModifiedDistanceRate && isFetchingWaypointsFromServer(transaction)) and isDistanceTransaction ? null : {…errors…}.
• Generic failure stamps errorFields on the transaction: UpdateMoneyRequest.ts:1913-1924.
• Rate-change recompute of merchant/amount: TransactionUtils/index.ts:718-764.
• getDistanceInMeters returns 0 without comment.customUnit.quantity/routes: getDistanceInMeters.ts:8-23.
• getDistanceMerchant / getFormattedRateValue return "Pending…"/"" when route, rate, currency, or unit are missing (the short "mi"/"km" unit only appears on the normal path): DistanceRequestUtils.ts:256-279, :151-174.
• Distance branch requires modified amount + merchant containing @: ModifiedExpenseMessage.ts:307-330, :124-146.
• Optimistic original message wires oldMerchant/merchant from modifiedMerchant: ReportUtils.ts:5942-5954.

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

Make the offline rate-only recompute produce a valid optimistic merchant/amount so a proper system message is shown and the params sent on reconnect are the ones the backend expects:

1. In getUpdatedTransaction's customUnitRateID branch, resolve the distance from the transaction's existing comment.customUnit.quantity/routes (it's already present for a submitted expense) and the unit/rate from the selected policy rate, so getDistanceMerchant(true, …) yields "X mi @ $Y / mi" rather than "Pending…"/"".
2. If a valid merchant/amount genuinely cannot be computed offline, suppress building the optimistic action for the rate change (as is already done when isFetchingWaypointsFromServer) instead of emitting a degenerate one, so behavior is consistent.
3. Verify the UpdateMoneyRequestDistanceRate params written offline are not zeroed, which is what triggers the backend rejection → genericEditFailureMessage RBR on reconnect.

Needs verification: which offline gap actually fires here — (a) getDistanceInMeters returning 0 because the optimistic transaction lacks quantity/routes at edit time, vs. (b) getRate failing to resolve unit/rate/currency for the newly-selected rate. A live offline repro (inspect the optimistic modifiedMerchant/modifiedAmount and the queued API params) or backend logs for the rejected UpdateMoneyRequestDistanceRate command would confirm the exact branch before implementing.

Related issues

Same offline distance-rate-edit area — likely related, worth cross-checking for a shared root cause:

• [Exploratory] Distance expense-Amount is changed to 0 after changing rate offline #94766 — Distance expense amount changes to 0 after changing rate offline
• [Due for payment 2026-08-17] [$250] Distance - Rate field is blank when distance is submitted from self DM offline #93575 — Rate field blank when distance submitted from self DM offline

---

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

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-15 19:26:19 UTC.

Proposal

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

Changing a distance expense's rate while offline shows no system message, and going back online surfaces two errors — "Receipt upload failed. Save the receipt, or delete the expense and lose it." and "Unexpected error creating this chat. Please try again later." — even though the rate change itself is applied.

What is the root cause of that problem?

Both errors are creation-time errors that belong to the expense being created, not to the rate edit. They are pushed together by the money‑request creation failureData: the transaction gets getReceiptError(...) ("Receipt upload failed…") and the chat/IOU report gets errorFields.createChat = report.genericCreateReportFailureMessage ("Unexpected error creating this chat…"):

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

Lines 995 to 1032 in 0154888

	// Standard flow
	onyxData.failureData?.push(
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${chat.report?.reportID}`,
	value: {
	iouReportID: chat.report?.iouReportID,
	lastReadTime: chat.report?.lastReadTime,
	lastVisibleActionCreated: chat.report?.lastVisibleActionCreated,
	pendingFields: null,
	hasOutstandingChildRequest: chat.report?.hasOutstandingChildRequest,
	...(isNewChatReport
	? {
	errorFields: {
	createChat: getMicroSecondOnyxErrorWithTranslationKey('report.genericCreateReportFailureMessage'),
	},
	}
	: {}),
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${iou.report.reportID}`,
	value: {
	pendingFields: null,
	errorFields: {
	...(shouldCreateNewMoneyRequestReport ? {createChat: getMicroSecondOnyxErrorWithTranslationKey('report.genericCreateReportFailureMessage')} : {}),
	},
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transaction.transactionID}`,
	value: {
	errors: getReceiptError(transaction.receipt, transaction.receipt?.filename, isScanRequest, errorKey, CONST.IOU.ACTION_PARAMS.MONEY_REQUEST, retryParams),
	pendingFields: clearedPendingFields,
	},
	},

So both errors are the signature of the expense-creation request itself failing on reconnect — not of the UPDATE_MONEY_REQUEST_DISTANCE_RATE request (the rate change is accepted, which is why the correct "changed the rate to … mi @ …" message still appears after coming online).

Why the creation fails: a distance expense's creation request is still in the offline queue when you open its transaction thread and go offline before it has been acknowledged. Editing the rate offline then fires updateMoneyRequestDistanceRate, which enqueues a separate UPDATE_MONEY_REQUEST_DISTANCE_RATE that mutates the still‑optimistic transaction (recomputes amount/merchant, flags merchant pending so the backend regenerates the receipt):

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

Lines 201 to 235 in 0154888

	if (currentRateID !== customUnitRateID || (isMovingTransactionFromTrackExpense && transactionUnit !== selectedRateUnit)) {
	// In the split flow, when editing we use SPLIT_TRANSACTION_DRAFT to save draft value
	if (isEditingSplit && transaction) {
	setDraftSplitTransaction(transaction.transactionID, splitDraftTransaction, {customUnitRateID}, policy, personalPolicy?.outputCurrency);
	navigateBack();
	return;
	}
	if (isEditing && transaction?.transactionID) {
	// Persist preference so the default stays in sync across the workspace (the same way as in the setMoneyRequestDistanceRate)
	setLastSelectedDistanceRate(policy, customUnitRateID);
	updateMoneyRequestDistanceRate({
	transaction,
	transactionThreadReport: report,
	parentReport,
	parentReportNextStep,
	rateID: customUnitRateID,
	policy,
	policyTagList: policyTags,
	policyCategories,
	currentUserAccountIDParam,
	currentUserEmailParam,
	isASAPSubmitBetaEnabled,
	updatedTaxAmount: taxAmount,
	updatedTaxCode: taxRateExternalID,
	updatedTaxValue: taxValue,
	delegateAccountID,
	isOffline,
	currentTransactionViolations,
	isTrackIntentUser,
	personalPolicyOutputCurrency: personalPolicy?.outputCurrency,
	});
	} else {
	setMoneyRequestDistanceRate(transaction, customUnitRateID, policy, shouldUseTransactionDraft(action));
	}

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

Lines 1199 to 1323 in 0154888

	function updateMoneyRequestDistanceRate({
	transaction,
	transactionThreadReport,
	parentReport,
	rateID,
	created,
	policy,
	policyTagList,
	policyCategories,
	currentUserAccountIDParam,
	currentUserEmailParam,
	isASAPSubmitBetaEnabled,
	updatedTaxAmount,
	updatedTaxCode,
	updatedTaxValue,
	parentReportNextStep,
	delegateAccountID,
	hash,
	transactions,
	transactionViolations,
	isOffline,
	shouldBuildOptimisticModifiedExpenseReportAction = true,
	distanceOriginalPolicy,
	currentTransactionViolations: currentTransactionViolationsParam,
	isTrackIntentUser,
	personalPolicyOutputCurrency,
	}: {
	transaction: OnyxEntry<OnyxTypes.Transaction>;
	transactionThreadReport: OnyxEntry<OnyxTypes.Report>;
	parentReport: OnyxEntry<OnyxTypes.Report>;
	rateID: string;
	created?: string;
	policy: OnyxEntry<OnyxTypes.Policy>;
	policyTagList: OnyxEntry<OnyxTypes.PolicyTagLists>;
	policyCategories: OnyxEntry<OnyxTypes.PolicyCategories>;
	currentUserAccountIDParam: number;
	currentUserEmailParam: string;
	isASAPSubmitBetaEnabled: boolean;
	updatedTaxAmount?: number;
	updatedTaxCode?: string;
	updatedTaxValue?: string;
	parentReportNextStep: OnyxEntry<OnyxTypes.ReportNextStepDeprecated>;
	delegateAccountID: number | undefined;
	hash?: number;
	transactions?: OnyxCollection<OnyxTypes.Transaction>;
	transactionViolations?: OnyxCollection<OnyxTypes.TransactionViolations>;
	isOffline?: boolean;
	shouldBuildOptimisticModifiedExpenseReportAction?: boolean;
	distanceOriginalPolicy?: OnyxEntry<OnyxTypes.Policy>;
	currentTransactionViolations?: OnyxEntry<OnyxTypes.TransactionViolations>;
	isTrackIntentUser: boolean | undefined;
	personalPolicyOutputCurrency: string | undefined;
	}) {
	const transactionChanges: TransactionChanges = {
	customUnitRateID: rateID,
	...(created ? {created} : {}),
	...(typeof updatedTaxAmount === 'number' ? {taxAmount: updatedTaxAmount} : {}),
	...(updatedTaxCode ? {taxCode: updatedTaxCode} : {}),
	...(updatedTaxValue ? {taxValue: updatedTaxValue} : {}),
	};
	if (transaction?.transactionID) {
	const existingDistanceUnit = transaction?.comment?.customUnit?.distanceUnit;
	const newDistanceUnit = DistanceRequestUtils.getRateByCustomUnitRateID({
	customUnitRateID: rateID,
	policy,
	})?.unit;
	// If the distanceUnit is set and the rate is changed to one that has a different unit, mark the merchant as modified to make the distance field pending
	if (existingDistanceUnit && newDistanceUnit && newDistanceUnit !== existingDistanceUnit) {
	transactionChanges.merchant = getMerchant(transaction);
	}
	}
	let data: UpdateMoneyRequestData<UpdateMoneyRequestDataKeys>;
	const currentTransactionViolations =
	currentTransactionViolationsParam ?? (transaction?.transactionID ? transactionViolations?.[`${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transaction.transactionID}`] : undefined);
	if (isTrackExpenseReport(transactionThreadReport) && isSelfDM(parentReport)) {
	data = getUpdateTrackExpenseParams(
	transaction?.transactionID,
	transactionThreadReport?.reportID,
	transactionChanges,
	policy,
	delegateAccountID,
	hash,
	shouldBuildOptimisticModifiedExpenseReportAction,
	distanceOriginalPolicy,
	currentTransactionViolations,
	personalPolicyOutputCurrency,
	);
	} else {
	data = getUpdateMoneyRequestParams({
	transactionID: transaction?.transactionID,
	transactionThreadReport,
	iouReport: parentReport,
	transactionChanges,
	policy,
	policyTagList,
	// TODO: Replace getPolicyTagsData (https://github.com/Expensify/App/issues/72721) with useOnyx hook
	reportPolicyTags: getPolicyTagsData(parentReport?.policyID),
	policyCategories,
	currentUserAccountIDParam,
	currentUserEmailParam,
	isASAPSubmitBetaEnabled,
	iouReportNextStep: parentReportNextStep,
	isOffline,
	hash,
	delegateAccountID,
	shouldBuildOptimisticModifiedExpenseReportAction,
	distanceOriginalPolicy,
	violations: currentTransactionViolations,
	isTrackIntentUser,
	personalPolicyOutputCurrency,
	});
	if (created && transaction?.transactionID && transactions && transactionViolations) {
	removeTransactionFromDuplicateTransactionViolation(data.onyxData, transaction.transactionID, transactions, transactionViolations);
	}
	}
	const {params, onyxData} = data;
	// `taxAmount`, `taxCode`, and optionally `created` only need to be updated in the optimistic data, so we need to remove them from the params
	const {taxAmount, taxCode, created: createdParam, ...paramsWithoutOptimisticOnlyData} = params;
	const paramsForAPI = createdParam ? {...paramsWithoutOptimisticOnlyData, created: createdParam} : paramsWithoutOptimisticOnlyData;
	API.write(WRITE_COMMANDS.UPDATE_MONEY_REQUEST_DISTANCE_RATE, paramsForAPI, onyxData);

On reconnect the update runs interleaved with the still‑pending create; the create is rejected and its failureData surfaces the two errors above.

Note: the previous hypothesis — that transactionChanges.merchant is never recorded for a same‑unit rate change, so no optimistic message is built — is not what happens here. The optimistic message's merchant comes from updatedTransaction.modifiedMerchant, which getUpdatedTransaction recomputes for every rate change (independent of that transactionChanges.merchant line):

App/src/libs/TransactionUtils/index.ts

Lines 737 to 763 in 0154888

	if (!isFetchingWaypointsFromServer(transaction)) {
	// When the waypoints are being fetched from the server, we have no information about the distance, and cannot recalculate the updated amount.
	// Otherwise, recalculate the fields based on the new rate.
	const updatedMileageRate = DistanceRequestUtils.getRate({transaction: updatedTransaction, policy, useTransactionDistanceUnit: false, personalPolicyOutputCurrency});
	const {unit, rate} = updatedMileageRate;
	const distanceInMeters = getDistanceInMeters(updatedTransaction, unit);
	const amount = DistanceRequestUtils.getDistanceRequestAmount(distanceInMeters, unit, rate ?? 0);
	const updatedAmount = isFromExpenseReport || isUnReportedExpense ? -amount : amount;
	const updatedCurrency = updatedMileageRate.currency ?? CONST.CURRENCY.USD;
	const updatedMerchant = DistanceRequestUtils.getDistanceMerchant(
	true,
	distanceInMeters,
	unit,
	rate,
	updatedCurrency,
	translateLocal,
	(digit) => toLocaleDigit(IntlStore.getCurrentLocale(), digit),
	getCurrencySymbol,
	isManualDistanceRequest(transaction),
	);
	updatedTransaction.amount = updatedAmount;
	updatedTransaction.modifiedAmount = updatedAmount;
	updatedTransaction.modifiedMerchant = updatedMerchant;
	updatedTransaction.modifiedCurrency = updatedCurrency;

So the optimistic MODIFIED_EXPENSE is well‑formed; the real defect is the racing creation, not the message.

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

Don't issue a separate UPDATE_MONEY_REQUEST_DISTANCE_RATE while the underlying expense is still pending creation — fold the new rate into the not‑yet‑sent create so a single request carries the final rate (offline‑first, no reconnect race).

selectDistanceRate already branches between editing an existing expense and setting the rate on a not‑yet‑created one:

if (isEditing && transaction?.transactionID) {
    updateMoneyRequestDistanceRate({...});
} else {
    setMoneyRequestDistanceRate(transaction, customUnitRateID, policy, shouldUseTransactionDraft(action));
}

We should treat a transaction whose creation is still pending (transaction.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD) like the create path — update the pending transaction's rate optimistically instead of firing an update command that races the create. This keeps the offline edit working (system message + recomputed amount) while removing the reconnect failure.

Note: canEditMoneyRequest already disables editing only when the create has failed (pendingAction === ADD && !isEmptyObject(errors)), not while it is merely pending — this is the exact window we need to handle:

App/src/libs/ReportUtils.ts

Lines 4966 to 4969 in 0154888

	// In case the transaction is failed to be created, we should disable editing the money request
	if (!linkedTransaction.transactionID || (linkedTransaction.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD && !isEmptyObject(linkedTransaction.errors))) {
	return false;
	}

What alternative solutions did you explore? (Optional)

• Sequence the update behind the create in the offline queue so UPDATE_MONEY_REQUEST_DISTANCE_RATE picks up the server‑assigned reportID/transactionID rather than the optimistic ones. More general, but a much larger change to the request‑queue / optimistic‑ID handling.
• Simply block editing the rate while the expense is pending creation (extend canEditMoneyRequest to the pending state). It removes the errors but also removes the offline feedback the issue expects at step 7, so folding the rate into the create is the better UX.

[MobileMage]

Proposal

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

On a workspace with multiple distance rates, editing the "Rate" of a distance expense from the transaction thread while offline should optimistically post a MODIFIED_EXPENSE system message showing the new rate/unit ("mi"/"km"). Instead, no system message appears while offline, and once the device reconnects and the queued UpdateMoneyRequestDistanceRate request is finally sent, the user sees an unexpected error instead of the message simply confirming or updating.

What is the root cause of that problem?

updateMoneyRequestDistanceRate in UpdateMoneyRequest.ts builds the optimistic MODIFIED_EXPENSE report action through getUpdateMoneyRequestParams, which calls buildOptimisticModifiedExpenseReportAction and pushes it into REPORT_ACTIONS optimistic data when the rate-change condition is met:

if (
    (!hasPendingWaypoints || hasSplitDistanceMessageFields || hasDistanceWithWaypoints) &&
    !(hasModifiedDistanceRate && isFetchingWaypointsFromServer(transaction)) &&
    updatedReportAction
) {

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

Lines 1684 to 1688 in 763218c

	if (
	(!hasPendingWaypoints || hasSplitDistanceMessageFields || hasDistanceWithWaypoints) &&
	!(hasModifiedDistanceRate && isFetchingWaypointsFromServer(transaction)) &&
	updatedReportAction
	) {

Immediately after, the failureData entry for that same reportActionID is built with an explicit carve-out for any distance transaction, regardless of whether the edit actually involves server-side waypoint/receipt regeneration:

const isDistanceTransaction = transaction && isDistanceRequestTransactionUtils(transaction);
failureData.push({
    onyxMethod: Onyx.METHOD.MERGE,
    key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${transactionThreadReport?.reportID}`,
    value: {[updatedReportAction.reportActionID]: isDistanceTransaction ? null : {...updatedReportAction, errors: getMicroSecondOnyxErrorWithTranslationKey('iou.error.genericEditFailureMessage')}},
});

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

Lines 1722 to 1735 in 763218c

	const isDistanceTransaction = transaction && isDistanceRequestTransactionUtils(transaction);
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${transactionThreadReport?.reportID}`,
	value: {
	[updatedReportAction.reportActionID]: isDistanceTransaction
	? null
	: {
	...(updatedReportAction as OnyxTypes.ReportAction),
	errors: getMicroSecondOnyxErrorWithTranslationKey('iou.error.genericEditFailureMessage'),
	},
	},
	});

This isDistanceTransaction ? null : … branch was written for waypoint edits, where the merchant/amount genuinely can't be computed client-side and the server is expected to push the real MODIFIED_EXPENSE action back via Pusher, so wiping the optimistic placeholder on failure is correct there. But isDistanceTransaction is derived purely from isDistanceRequestTransactionUtils(transaction) — it doesn't distinguish a pure rate edit (which is fully computable client-side, see getUpdatedTransaction's customUnitRateID branch that eagerly recalculates modifiedAmount/modifiedMerchant/comment.customUnit.distanceUnit without needing the server) from a waypoint-driven edit. Because the request is queued while offline and only actually reaches the API once the app reconnects, any failure surfaced at that point (stale customUnitRateID, an out-of-range violation recomputed against fresher server-side policy data, etc.) causes this same code path to silently null out the queued MODIFIED_EXPENSE action — the system message the user saw (or should have seen) while offline simply vanishes instead of showing an error, while the separate errorFields/pendingFields error (iou.error.genericEditFailureMessage) set earlier in the same function still fires and is what the user perceives as the "unexpected error" popping up only after going back online.

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

The failureData branch at UpdateMoneyRequest.ts#L1722-L1735 should only null out the optimistic report action for edits where the server truly must recompute the message (i.e. when waypoints changed and we could not build a valid optimistic message client-side), not for every distance transaction. Concretely, replace the blanket isDistanceTransaction check with the same hasPendingWaypoints && !hasSplitDistanceMessageFields && !hasDistanceWithWaypoints gate already used to decide whether to skip building the optimistic action in the first place, so a pure rate change always falls back to the normal error-attached failureData:

const shouldClearActionOnFailure = hasPendingWaypoints && !hasSplitDistanceMessageFields && !hasDistanceWithWaypoints;
value: {[updatedReportAction.reportActionID]: shouldClearActionOnFailure ? null : {...updatedReportAction, errors: getMicroSecondOnyxErrorWithTranslationKey('iou.error.genericEditFailureMessage')}},

This keeps the existing (correct) behavior for waypoint-driven distance edits while making rate-only edits behave like any other transaction edit: the optimistic message stays visible offline, and on a genuine replay failure it gets a visible inline error (RBR + tooltip) instead of disappearing and being replaced by an opaque global error toast.

What alternative solutions did you explore? (Optional)

An alternative is to keep the current null-out behavior but surface a dedicated toast/alert when a distance-rate-only edit fails after reconnecting, so the user at least knows which action failed; this was rejected because it duplicates the existing inline-error mechanism (errors on the report action) that every other transaction edit already relies on, adding a second, inconsistent error-reporting path instead of just correctly scoping the existing one.

[aswin-s]

Proposal

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

On Web, when a user with a workspace that has multiple distance rates edits the rate of a submitted distance expense while offline, no system message is emitted for the rate change, and an "Unexpected error" is thrown when the client goes back online and the queued UpdateMoneyRequestDistanceRate request is flushed to the server. Expected: the ModifiedExpense system message should appear immediately using the short unit ("mi"/"km"), and the request should succeed with no error when connectivity is restored.

What is the root cause of that problem?

The call site in src/pages/iou/request/step/IOURequestStepDistanceRate.tsx at line 213 invokes updateMoneyRequestDistanceRate({...}) but never passes the distanceOriginalPolicy field (compare the props actually forwarded on lines 213–234 to the accepted params at [src/libs/actions/IOU/UpdateMoneyRequest.ts:1225](https://github.com/Expensify/App/blob/763218ccf3a286f440f26ee11af5bab42a8f4007/src/libs/actions/IOU/UpdateMoneyRequest.ts#L1225)–1256). As a result, distanceOriginalPolicy arrives as undefined at UpdateMoneyRequest.ts:1293 / :1315. For the non-track (workspace-chat) branch, getUpdateMoneyRequestParams therefore has no distanceOriginalPolicy to fall back on when building the ModifiedExpense report action, so the rate/unit lookup produces no change message; more importantly, unlike getUpdateTrackExpenseParams (which was patched in PR #87537 to set params.policyID = policyForTransaction?.id around UpdateMoneyRequest.ts:1575), the workspace-chat path in getUpdateMoneyRequestParams never attaches a policyID derived from the rate-owning policy to the API params — so once the request drains after going online, the backend cannot resolve the newly selected customUnitRateID against the correct policy and returns the unexpected error.

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

1. src/pages/iou/request/step/IOURequestStepDistanceRate.tsx (~lines 27, 213–234): call useDistanceRateOriginalPolicy(customUnitRateID) (already used in MoneyRequestView.tsx) and pass the resulting distanceOriginalPolicy to updateMoneyRequestDistanceRate({...}).
2. src/libs/actions/IOU/UpdateMoneyRequest.ts getUpdateMoneyRequestParams (around the params construction near line 2006 and the workspace-chat apiParams builder analogous to the track path at ~line 1575): add policyID: policyForTransaction?.id to the API params so the backend receives the rate-owning policy, and use policyForTransaction = distanceOriginalPolicy ?? policy (mirroring :2190) when building getUpdatedTransaction / the modified-expense action, so the ModifiedExpense system message can resolve the rate name/unit and be emitted optimistically.
3. src/libs/API/parameters/UpdateMoneyRequestParams.ts: policyID was already added by PR Preserve distance rate for unreported expenses from non-default policies #87537 — no change needed, but confirm this file exposes it for the distance-rate write path used by the workspace-chat branch.
4. Audit sibling entry points that also invoke updateMoneyRequestDistanceRate / updateMoneyRequestDistance (e.g. the date-change recalculation branch at UpdateMoneyRequest.ts:256, and IOURequestStepDistance.tsx) to ensure each one forwards distanceOriginalPolicy — the date-recalc branch already threads it, but the distance-rate step does not.

What alternative solutions did you explore? (Optional)

[samranahm]

Proposal

What is the root cause of that problem?

When a user edits a distance rate offline from the transaction thread, two things go wrong: no "changed rate" system message appears, and once the client reconnects an unexpected error is thrown.

The rate edit is handled by updateMoneyRequestDistanceRate in IOU.ts. This function builds the optimistic MODIFIEDEXPENSE report action and the optimistic transaction update. The merchant shown in the distance system message is generated by getDistanceMerchant in DistanceRequestUtils.ts, and the human readable "changed X to Y" text is produced by getForReportAction in ModifiedExpenseMessage.ts.

https://github.com/Expensify/App/blob/763218ccf3a286f440f26ee11af5bab42a8f4007/src/libs/DistanceRequestUtils.ts

https://github.com/Expensify/App/blob/763218ccf3a286f440f26ee11af5bab42a8f4007/src/libs/actions/IOU.ts

The offline optimistic path recomputes the merchant/amount from the newly selected rate, but the optimistic MODIFIEDEXPENSE action is missing the oldValue/newValue fields (or stores them in a shape getForReportAction cannot read), so ModifiedExpenseMessage returns an empty string and no system message is rendered. When the client goes back online, the server response returns the modified expense action with the fully populated unit/merchant fields, and the reconciliation of that server payload against the incomplete optimistic action hits code in getDistanceMerchant / getForReportAction that expects a defined unit and rate, which is where the unexpected error surfaces.

The gap: today the optimistic data for a distance rate change does not carry the same modified-field shape (unit, rate, merchant) the backend returns, so the message is empty offline and the merge throws online.

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

1. In updateMoneyRequestDistanceRate in IOU.ts, ensure the optimistic MODIFIEDEXPENSE report action includes the old and new merchant and rate values so ModifiedExpenseMessage.getForReportAction can build the system message.

https://github.com/Expensify/App/blob/763218ccf3a286f440f26ee11af5bab42a8f4007/src/libs/actions/IOU.ts

const optimisticModifiedAction = ReportUtils.buildOptimisticModifiedExpenseReportAction(transactionThread, oldTransaction, transactionChanges, ...);

Populate transactionChanges with the recomputed merchant (via getDistanceMerchant) and the rate so the modified action mirrors the backend shape.

2. In getForReportAction in ModifiedExpenseMessage.ts, guard the distance branch so it renders the short unit ("mi"/"km") from getDistanceMerchant even when only the rate changes, instead of returning empty when the merchant delta is not present.

https://github.com/Expensify/App/blob/763218ccf3a286f440f26ee11af5bab42a8f4007/src/libs/DistanceRequestUtils.ts

3. In getDistanceMerchant in DistanceRequestUtils.ts, add a defensive fallback so an undefined unit or rate returns a safe merchant string rather than throwing, which stops the crash when the server payload merges over the optimistic action after reconnect.

if (!rate || !unit) {
    return '';
}

This makes the offline optimistic action carry the same fields the server returns, so the system message shows immediately offline and the online reconciliation no longer hits an undefined value.

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.

[ahmdshrif]

Proposal

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

When a distance rate is edited offline on a transaction, no "changed the rate" system message appears in the transaction thread, and once the user goes back online an unexpected error is shown.

What is the root cause of that problem?

The optimistic path for a rate edit only marks the merchant field (which encodes distance @ rate) as changed when the unit changes, not when only the rate value changes. In updateMoneyRequestDistanceRate, the merchant is added to transactionChanges only under newDistanceUnit !== existingDistanceUnit:

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

Lines 1266 to 1277 in 763218c

	if (transaction?.transactionID) {
	const existingDistanceUnit = transaction?.comment?.customUnit?.distanceUnit;
	const newDistanceUnit = DistanceRequestUtils.getRateByCustomUnitRateID({
	customUnitRateID: rateID,
	policy,
	})?.unit;
	// If the distanceUnit is set and the rate is changed to one that has a different unit, mark the merchant as modified to make the distance field pending
	if (existingDistanceUnit && newDistanceUnit && newDistanceUnit !== existingDistanceUnit) {
	transactionChanges.merchant = getMerchant(transaction);
	}
	}

For a same-unit rate change (e.g. mi→mi) the merchant is never included, so the optimistic MODIFIED_EXPENSE action has no merchant/oldMerchant. ModifiedExpenseMessage only renders the distance "changed the rate" line when both amount and merchant were modified:

App/src/libs/ModifiedExpenseMessage.ts

Lines 307 to 330 in 763218c

	if (hasModifiedAmount) {
	const oldCurrency = reportActionOriginalMessage?.oldCurrency;
	const oldAmountValue = reportActionOriginalMessage?.oldAmount ?? 0;
	const oldAmount = convertToDisplayString(oldAmountValue, oldCurrency);
	const currency = reportActionOriginalMessage?.currency;
	const amount = convertToDisplayString(reportActionOriginalMessage?.amount ?? 0, currency);
	// Only Distance edits should modify amount and merchant (which stores distance) in a single transaction.
	// We check the merchant is in distance format (includes @) as a sanity check
	if (hasModifiedMerchant && (reportActionOriginalMessage?.merchant ?? '').includes('@')) {
	const distanceMessage = getForDistanceRequest(translate, reportActionOriginalMessage?.merchant ?? '', reportActionOriginalMessage?.oldMerchant ?? '', amount, oldAmount);
	// A date edit that moves the expense into a different mileage-rate window bundles the rate and the date
	// change into a single MODIFIED_EXPENSE action. getForDistanceRequest only describes the rate/distance
	// change, so append the date change here instead of letting it be dropped by the early return.
	const dateChangeFragments: string[] = [];
	buildDateChangeFragment(translate, reportActionOriginalMessage?.oldCreated, reportActionOriginalMessage?.created, [], [], dateChangeFragments);
	if (dateChangeFragments.length > 0) {
	return `${distanceMessage}${getMessageLine(translate, `\n${translate('iou.changed')}`, dateChangeFragments)}`;
	}
	return distanceMessage;
	}

Hence no offline system message. When the client goes online the server returns a ModifiedExpense action whose originalMessage carries the merchant/rate fields the optimistic action lacked; the shape mismatch surfaces as the "unexpected error".

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

Always reflect the rate change in the merchant so the optimistic action matches the server payload — include the recalculated merchant in transactionChanges for any rate change, not only unit changes:

// UpdateMoneyRequest.ts ~L1273
if (existingDistanceUnit && newDistanceUnit) {
    // include merchant on every rate change so the "`@rate`" segment updates optimistically
    transactionChanges.merchant = getMerchant(transaction);
}

This makes getForDistanceRequest see a modified merchant and render "changed the rate from X to Y" offline, and keeps optimistic/server originalMessage shapes aligned so no error is thrown online. Regression check: confirm same-unit rate edits, cross-unit rate edits, and pure distance edits still each produce exactly one correct system message.

[melvin-bot]

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

[melvin-bot]

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