[Due for payment 2026-09-17] Amount shows infinite symbol, Rate shows pending when submitting distance from self DM

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.59-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/70387618/folder/13176877/41237352/1686037292?sort=-identifier
Email or phone of affected tester (no customers): sdsiodjnosdjiodsj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to self DM.
3. Create a distance expense.
4. Quickly click Submit to a friend and select workspace chat before map is generated on the expense preview.

Expected Result:

• Confirm page will open immediately.
• Amount will show the correct expense amount.
• Rate will show workspace rate.

Actual Result:

• App freezes for a while before confirm page opens.
• Amount shows infinite symbol ♾️.
• Rate shows pending and is not editable.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7240044_1787402220079.7.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7240044

Issue Owner

Current Issue Owner: @mallenexpensify

[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/9828947678d8ca79f8514ac89401517c798f529abe2c9d12a4a076a7293de5cc

[MelvinBot]

Proposal

What is the root cause of that problem?

Both symptoms (amount ♾️ + rate stuck on "pending") come from the same race: the user moves the distance expense from the self DM to a workspace while the map route is still being generated, so the workspace rate hasn't resolved and the transaction's distance/quantity is still 0.

A self‑DM distance expense is a Track Expense, so switching it to a workspace makes isMovingTransactionFromTrackExpense = true. In useDistanceRequestState.ts:87‑90 that flips the rate into "back‑calculate from the transaction" mode because the workspace distanceRate is still falsy:

const calculateFromTransactionData = isMovingTransactionFromTrackExpense && !distanceRate;
const rate = calculateFromTransactionData ? Math.abs(iouAmount) / (customUnit?.quantity ?? 1) : distanceRate;

While the route is pending, customUnit.quantity is 0. The ?? 1 fallback only guards null/undefined, not 0, so with a non‑zero seeded iouAmount this is a division by zero → rate = Infinity. That flows into getDistanceRequestAmount (round(distance * Infinity) = Infinity), and Intl.NumberFormat renders Infinity as the ♾️ symbol.

Normally the amount is blanked while a route is pending, but that guard is deliberately disabled for track‑expense moves at useDistanceRequestState.ts:110 (&& !isMovingTransactionFromTrackExpense), so the bad value is shown (and persisted) instead of hidden.

The rate row is a separate value: RateField.tsx:97‑110 reads mileageRate.rate (the unresolved workspace rate = undefined), so getFormattedRateValue returns iou.fieldPending and isRateInteractive is false — hence "pending" and non‑editable. That's why the amount is ♾️ while the rate simultaneously shows "pending".

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

Treat a still‑pending route as pending during a track‑expense move instead of back‑calculating against a zero quantity:

1. In useDistanceRequestState.ts, guard the divisor against 0 (not just nullish) — e.g. only back‑calculate when customUnit?.quantity is a positive number; otherwise treat the rate as unresolved (undefined). This stops the Infinity.
2. Don't bypass the pending‑route blanking while the route is genuinely still pending. Line 110 should keep isDistanceRequestWithPendingRoute true when there is no route/quantity yet, even for a track‑expense move, so the amount shows blank/pending until the route resolves rather than a garbage value.

Net effect: while the map is generating, amount and rate both read "pending", and once the route + workspace rate resolve, both fill in with the correct workspace values.

Data flow & evidence

1. Distance expense started in self DM (a Track Expense); route request is async, so routes.route0.distance and customUnit.quantity are 0, but a non‑zero iouAmount is seeded from the P2P rate.
2. User submits and picks a workspace chat → isMovingTransactionFromTrackExpense = true.
3. Workspace distanceRate not resolved yet → calculateFromTransactionData = true.
4. rate = Math.abs(iouAmount) / (0 ?? 1) → Math.abs(iouAmount) / 0 = Infinity (?? 1 does not catch 0).
5. distanceRequestAmount = round(distance * Infinity) = Infinity; blanking guard bypassed at line 110 → shown & persisted via DistanceRequestController.tsx setMoneyRequestAmount.
6. CurrencyUtils.convertToDisplayString → Intl.NumberFormat.format(Infinity) → ♾️.
7. Rate row reads mileageRate.rate (undefined) → "pending" + non‑interactive.

Note: if iouAmount were 0, the divide would be 0/0 = NaN and render "NaN" — the reported ♾️ confirms a non‑zero seeded amount survived from the self‑DM P2P computation.

What alternative solutions did you explore? (Optional)

Alternatively, ensure setCustomUnitRateID (MoneyRequest.ts:710‑767) defers finalizing the amount until the route resolves, but the minimal, targeted fix is the two guards above.

Possibly related: #98426 (rate not editable / "Rate not valid" on distance submit) touches the same rate‑resolution area — worth cross‑checking, though it does not describe the ♾️ amount.

---

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

---

view run

[melvin-bot]

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

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[dilshodmackbook-sketch]

@ZhenjaHorbach I'd like to offer a proposal. One note on the original analysis first: it states that routes.route0.distance and customUnit.quantity are both 0 and that distanceRequestAmount = round(distance * Infinity) = Infinity. Those two can't both hold — 0 * Infinity = NaN, which would render "NaN", not ♾️. The ♾️ symbol only appears when the route distance has already resolved (non-zero) while quantity is still 0. That distinction matters: it means the pending-route blanking (line 110) never fires in this repro, and the route distance is available to keep the amount correct during the race.

Proposal

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

When a distance expense is created in the self DM (a Track Expense) and the user quickly submits it to a workspace chat before the route/map finishes generating, the confirmation page persists the amount as ♾️ and shows the rate as "pending" (non-editable).

What is the root cause of that problem?

A self-DM distance expense is a Track Expense, so moving it to a workspace makes isMovingTransactionFromTrackExpense = true. While the workspace mileage rate hasn't resolved, distanceRate is still falsy, so the hook switches into "back-calculate the rate from the transaction" mode:

App/src/components/MoneyRequestConfirmationList/hooks/useDistanceRequestState.ts

Lines 87 to 90 in 063b4d0

	const calculateFromTransactionData = isMovingTransactionFromTrackExpense && !distanceRate;
	const customUnit = transaction?.comment?.customUnit;
	const unit = calculateFromTransactionData ? customUnit?.distanceUnit : distanceUnit;
	const rate = calculateFromTransactionData ? Math.abs(iouAmount) / (customUnit?.quantity ?? 1) : distanceRate;

const calculateFromTransactionData = isMovingTransactionFromTrackExpense && !distanceRate;
...
const rate = calculateFromTransactionData ? Math.abs(iouAmount) / (customUnit?.quantity ?? 1) : distanceRate;

Key detail on the transaction state: the route response has already populated transaction.routes.route0.distance, but comment.customUnit.quantity is only set once the request is finalized. So at this moment quantity is 0 while the route distance is a real, non-zero value — see the priority in getDistanceInMeters, which prefers quantity and otherwise falls back to the route distance:

App/src/libs/TransactionUtils/getDistanceInMeters.ts

Lines 11 to 28 in 063b4d0

	function getDistanceInMeters(transaction: OnyxInputOrEntry<Transaction>, unit: Unit | undefined) {
	// If the request is completed, transaction.routes is cleared and comment.customUnit.quantity holds the new distance in the selected unit.
	// We need to convert it from the selected distance unit to meters.
	// This check takes priority because after a manual distance edit, routes.route0.distance may still
	// hold a stale route-calculated value while quantity reflects the user's intended distance.
	if (transaction?.comment?.customUnit?.quantity && unit) {
	return DistanceRequestUtils.convertToDistanceInMeters(transaction.comment.customUnit.quantity, unit);
	}
	// If we are creating a new distance request, the distance is available in routes.route0.distance and it's already in meters.
	// `getSelectedRouteKey` resolves the route the user picked (falling back to route0), so an alternate route wins here.
	const selectedRouteKey = getSelectedRouteKey(transaction);
	const selectedRouteDistance = transaction?.routes?.[selectedRouteKey]?.distance ?? transaction?.routes?.[CONST.TRANSACTION.DEFAULT_ROUTE_KEY]?.distance;
	if (selectedRouteDistance) {
	return selectedRouteDistance;
	}
	return 0;

The ?? 1 fallback only substitutes for null/undefined, not 0. With quantity = 0 and a non-zero seeded P2P iouAmount, this is a division by zero → rate = Infinity. Because the route distance has resolved, distance is non-zero, so:

App/src/libs/DistanceRequestUtils.ts

Lines 308 to 324 in 063b4d0

	*/
	function roundDistanceAmount(distanceInUnits: number, rate: number): number {
	const roundedDistance = parseFloat(distanceInUnits.toFixed(2));
	return Math.round(roundedDistance * rate);
	}
	/**
	* Calculates the expense amount based on distance, unit, and rate.
	*
	* @param distance - The distance traveled in meters
	* @param unit - The unit of measurement for the distance
	* @param rate - Rate used for calculating the expense amount
	* @returns The computed expense amount (rounded) in "cents".
	*/
	function getDistanceRequestAmount(distance: number, unit: Unit, rate: number): number {
	return roundDistanceAmount(convertDistanceUnit(distance, unit), rate);
	}

round(nonZeroDistance * Infinity) = Infinity, which is persisted via setMoneyRequestAmount and rendered by Intl.NumberFormat.format(Infinity) as ♾️.

This is exactly why the reported symbol is ♾️ and not "NaN": if the route distance had not resolved, distance would be 0, and 0 * Infinity = NaN would render "NaN". The ♾️ proves the route distance resolved while quantity had not — i.e. hasRoute is already true, so isDistanceRequestWithPendingRoute at line 110 never fires here.

The Rate row is a separate value: it reads the still-unresolved workspace mileageRate.rate (undefined), so getFormattedRateValue returns iou.fieldPending and isRateInteractive is false — hence "pending" and non-editable until the workspace rate resolves.

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

1. Resolve the rate at the source (primary). Credit to mukhrr for pinning the deeper cause: a self-DM track distance expense carries the source workspace's rate ID, which the destination workspace may not own, so getRate can't resolve it. The newer IOURequestStepConfirmation path already re-selects the destination rate; the legacy participant path (useParticipantSubmission.ts) skips it for track moves. Mirror that check there:

} else if (drafts.length > 0) {
    for (const transaction of drafts) {
        const currentRateID = transaction?.comment?.customUnit?.customUnitRateID;
        const isCurrentRateFromWorkspace = !!currentRateID && !!DistanceRequestUtils.getMileageRates(policy)[currentRateID];
        const shouldKeepCurrentRate = DistanceRequestUtils.isUnsetDistanceCustomUnitRateID(currentRateID) || isCurrentRateFromWorkspace;
        if (shouldKeepCurrentRate) {
            continue;
        }
        const rateID = DistanceRequestUtils.getCustomUnitRateID({reportID: firstParticipantReportID, isPolicyExpenseChat, policy, lastSelectedDistanceRates: distanceRates, expenseDate: transaction.created});
        setCustomUnitRateID(transaction.transactionID, rateID, transaction, policy, false, personalPolicy?.outputCurrency);
    }
}

With the rate resolved before confirmation renders, calculateFromTransactionData stays false, the divide never runs, the "Rate not valid for this workspace" error clears, and the Rate row shows the real workspace rate.

2. Guard the divide-by-zero (data integrity). The Math.abs(iouAmount) / (customUnit?.quantity ?? 1) is not only a display glitch: when the rate is unresolved for any reason (offline, the destination policy's rates not loaded yet when the user acts quickly, or a workspace with no matching rate), the result is Infinity, which DistanceRequestController persists via setMoneyRequestAmount. I read the draft back after it renders — the stored amount is Infinity, and JSON.stringify(Infinity) === "null", so the expense can be persisted/submitted with a null amount. Guarding the divisor stops this at the source regardless of why the rate is unresolved:

Only back-calculate the temporary rate from a positive divisor expressed in the selected distance unit, and prefer the value that is already available so the correct amount stays visible during the race instead of dividing by zero.

customUnit.quantity is already in the selected unit (mi/km). The route distance is available too, but in meters — so it must be converted to the selected unit before it can be used as the divisor. If we divide by raw meters, the recovered rate (and the displayed amount) is off by the meters→unit factor (METERS_TO_MILES ≈ 1609x, METERS_TO_KM = 1000x).

In useDistanceRequestState.ts:

const routeDistanceInUnit = calculateFromTransactionData && !customUnit?.quantity && unit ? DistanceRequestUtils.convertDistanceUnit(getDistanceInMeters(transaction, unit), unit) : 0;
// `||` (not `??`) is intentional: a pending `quantity` of 0 must fall through to the converted route distance.
const backCalculationDivisor = customUnit?.quantity || routeDistanceInUnit;
const rate = calculateFromTransactionData && backCalculationDivisor ? Math.abs(iouAmount) / backCalculationDivisor : distanceRate;

• With quantity = 0 but a resolved route distance, the divisor becomes the route distance converted to the selected unit, so rate is finite and distanceRequestAmount equals the seeded amount — no more ♾️, and the correct amount stays visible (matching the Expected Result) rather than blanking to 0.
• When neither a quantity nor a route distance is available yet, backCalculationDivisor is 0, so rate falls back to the still-undefined workspace distanceRate and the amount stays pending until the workspace rate resolves.
• No change to line 110 is needed: in this repro the route distance is already resolved (hasRoute is true), so the pending-route path isn't reached.

For the Rate row (so it no longer shows "pending" during the race), surface the same back-calculated (effective) rate in the field that reads mileageRate.rate, display-only, while DistanceRequestController keeps validating against the original mileageRate. In MoneyRequestConfirmationList.tsx, pass a display rate to the Rate field:

const rateFieldMileageRate = calculateFromTransactionData && rate ? {...mileageRate, rate} : mileageRate;

Both the amount and the rate are then derived from the same optimistically available data (seeded amount + resolved route distance) and automatically switch to the workspace values once the workspace rate loads.

Draft PR (with the failing test): #99580

What specific scenarios should we cover in automated tests to prevent this regression from happening in the future?

Unit test for useDistanceRequestState with isMovingTransactionFromTrackExpense = true, workspace distanceRate undefined, customUnit.quantity = 0, a non-zero iouAmount, and a resolved route distance (in meters):

• Assert distanceRequestAmount is finite (not ♾️) and equals the seeded amount — i.e. the correct amount stays visible during the race.
• Assert the raw-meters divisor path under-reports the amount by the meters→unit factor (~1609x), pinning why the route distance must be converted to the selected unit first.
• Regression: once distanceRate resolves to the workspace rate, rate and distanceRequestAmount equal the workspace-rate computation.

(These are on the branch above and pass with the fix / fail without it.)

What alternative solutions did you explore? (Optional)

• Guard calculateFromTransactionData with && !!customUnit?.quantity only (blank the amount to 0). This stops the ♾️, but shows a blank/0 amount during the race instead of the correct amount — weaker than the Expected Result.
• Divide by the route distance in raw meters (skip the unit conversion). Stops the ♾️ and keeps a finite amount, but under-reports it by the meters→unit factor (~1609x for miles), so the displayed amount is wrong.
• Re-enable the pending-route blanking by dropping && !isMovingTransactionFromTrackExpense on line 110 — in this specific race the route distance is already resolved, so that guard wouldn't fire; the divide-by-zero is the real cause.
• Defer finalizing the amount in setCustomUnitRateID until the route resolves — broader and more invasive than the targeted guard above.

[nkdengineer]

@ZhenjaHorbach In this case, quantity is missing but the distance and amount are already calculated. So we should use the available data to calculate it instead. From my log, routeDistanceMeters is available when the distance is calculated on the confirmation page. So we can use this data as a fallback when quantity is not available and only blocking calculateFromTransactionData if both of quantity and routeDistanceMeters are not available. Can write a detailed proposal if needed.

[dilshodmackbook-sketch]

@nkdengineer glad we're aligned on the root cause — that's exactly the state I described above: the route distance has already resolved while quantity is still 0, which is why the amount comes out as ♾️ (a resolved distance * Infinity) rather than NaN.

On the fallback idea, one correctness detail worth calling out before it gets implemented: customUnit.quantity is stored in the selected distance unit (mi/km), but routeDistanceMeters is in meters. Since the back-calculation is rate = |iouAmount| / divisor and the amount is later recomputed as convertDistanceUnit(meters, unit) * rate, the divisor has to be the route distance converted to that unit, not raw meters. If we divide by meters directly, the recovered rate — and therefore the displayed amount — is off by the meters→unit factor (METERS_TO_MILES ≈ 1609× for miles, 1000× for km):

App/src/libs/DistanceRequestUtils.ts

Lines 126 to 135 in 063b4d0

	function convertDistanceUnit(distanceInMeters: number, unit: Unit): number {
	switch (unit) {
	case CONST.CUSTOM_UNITS.DISTANCE_UNIT_KILOMETERS:
	return distanceInMeters * METERS_TO_KM;
	case CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES:
	return distanceInMeters * METERS_TO_MILES;
	default:
	throw new Error('Unsupported unit. Supported units are "mi" or "km".');
	}
	}

So the complete guard is: back-calculate only when we have a positive divisor, preferring quantity and falling back to the route distance in the selected unit; otherwise treat the rate as unresolved so it stays pending until the workspace rate loads:

const routeDistanceInUnit = unit ? DistanceRequestUtils.convertDistanceUnit(getDistanceInMeters(transaction, unit), unit) : 0;
const divisor = customUnit?.quantity || routeDistanceInUnit;
const rate = calculateFromTransactionData && divisor ? Math.abs(iouAmount) / divisor : distanceRate;

This keeps the correct amount visible during the race (instead of blanking it) while still avoiding the divide-by-zero, and it correctly falls through to "pending" when neither the quantity nor the route distance is available yet. Happy to fold this into the proposal.

[nkdengineer]

glad we're aligned on the root cause — that's exactly the state I described above: the route distance has already resolved while quantity is still 0, which is why the amount comes out as ♾️ (a resolved distance * Infinity) rather than NaN.

RCA already mentioned by Melvin.

On the fallback idea, one correctness detail worth calling out before it gets implemented: customUnit.quantity is stored in the selected distance unit (mi/km), but routeDistanceMeters is in meters. Since the back-calculation is rate = |iouAmount| / divisor and the amount is later recomputed as convertDistanceUnit(meters, unit) * rate, the divisor has to be the route distance converted to that unit, not raw meters. If we divide by meters directly, the recovered rate — and therefore the displayed amount — is off by the meters→unit factor (METERS_TO_MILES ≈ 1609× for miles, 1000× for km):

Nope. That doesn't what I mean when using the fallback. Of course we need to skip to conversion as it's already in meter. My idea is updating the util to fallback to this data without converting again as it's already in meter. And check the same for other places.

[ZhenjaHorbach]

@nkdengineer
Your theory sounds promising
Can you create a proposal, please?

[nkdengineer]

Proposal

What is the root cause of that problem?

Two related failures when submitting a distance expense quickly or offline from self DM to a workspace (“Submit to a friend”).

1. ∞ amount and Pending rate

After submit, the UI reads distance from comment.customUnit.quantity once routes are gone. getDistanceInMeters prefers quantity, then live routes, else 0. On a fast/offline submit, quantity is often missing while the map is still loading.

useDistanceRequestState then derives a temporary rate when moving off a track expense before the workspace rate loads:

Math.abs(iouAmount) / (customUnit?.quantity ?? 1)

A missing or zero quantity divides into Infinity. The real policy rate is still absent, so the rate row shows Pending (getFormattedRateValue). Moving-from-track skips the pending-route amount blank-out (isDistanceRequestWithPendingRoute), so the broken amount stays visible.

Optimistic submit can already keep routeDistanceMeters (buildOptimisticTransaction, MoneyRequestBuilder), but distance readers ignore it when quantity and routes are absent.

2. Missing customUnitRateID offline → rate error on “Submit to a friend”

useExpenseSubmission submits via trackExpenseIOUActions with existingTransaction: item, where item comes from useOptimisticDraftTransactions(initialTransaction). With a single draft, that is the same object reference as initialTransaction.

Confirm defers createTransaction (SubmitExpenseOrchestrator). During that gap the confirmation page can re-render while its distance writers (DistanceRequestController → setMoneyRequestMerchant / setMoneyRequestAmount / setMoneyRequestCommuterExclusionFields) do not rebuild customUnit. For self DM, commuter exclusion returns without writing.

Meanwhile buildOptimisticTransaction assigns the live draft’s customUnit by reference:

lodashSet(commentJSON, 'customUnit', existingTransaction?.comment?.customUnit ?? {});

lodash.set does not clone. Later sets (customUnit.distanceUnit, customUnit.customUnitRateID, …) mutate item.comment.customUnit while trackExpenseIOUActions is running. If customUnitRateID from params is empty or the nested sets overwrite the rate the confirmation page had selected, the optimistic expense loses the workspace rate ID and the confirmation flow shows a rate error when the default workspace is applied offline.

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

Distance / amount (do one or both)

1. Read routeDistanceMeters when quantity/routes are missing. In getDistanceInMeters, after the quantity and selected-route checks, if comment.customUnit.routeDistanceMeters is a positive number, return it (it is already in meters).

2. Seed quantity on optimistic create/submit when confirmation already knows the distance. In buildOptimisticTransaction and the submit path in MoneyRequestBuilder, set customUnit.quantity from the calculated distance or from routeDistanceMeters converted into the request unit.

Confirmation rate math

In useDistanceRequestState:

• Set calculateFromTransactionData to false when neither quantity nor routeDistanceMeters (nor a resolved route distance) is available. Do not derive a rate from transaction data with no distance.
• Guard the track-move fallback: only divide iouAmount / quantity when quantity is a positive number; otherwise wait on the policy rate.

customUnitRateID / mutation

3. Clone customUnit in buildOptimisticTransaction so nested lodash.set calls never mutate the live Onyx draft (distance block in TransactionUtils/index.ts):

lodashSet(commentJSON, 'customUnit', {...(existingTransaction?.comment?.customUnit ?? {})});
// same for the explicit customUnit branch: {...customUnit}

Only write customUnit.customUnitRateID when the param is defined. Preserve the existing rate when the param is absent.

4. Resolve customUnitRateID in getTrackExpenseInformation from transactionParams.customUnitRateID with fallback to getRateID(existingTransactionData), so the rate selected on confirmation survives into the optimistic transaction and into createdWorkspaceParams / submitTrackedExpenseToPolicy (submit path in TrackExpense.ts).

What alternative solutions did you explore? (Optional)

1. Only fall back to routeDistanceMeters in the confirmation hook — leaves other getDistanceInMeters callers broken in the same race.
2. Only seed optimistic quantity — still fails when distance was never computed before submit.
3. Snapshot the transaction in useExpenseSubmission before calling trackExpenseIOUActions — avoids mutation but duplicates data; cloning at the writer (buildOptimisticTransaction) fixes all callers.
4. Re-apply rate on reconnect — does not fix offline validation errors before the request is sent.