[$250] Distance - After changing distance to 0 and changing rate, Amount does not retain 0.00 value

[jponikarchuk]

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: 9.3.9-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: #79197
Email or phone of affected tester (no customers): sdosjosjdoijosjosidj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.1 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Distance rates are enabled.
• Workspace has at least two different rates.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Click + > Track distance > Manual.
4. Enter amount > Next.
5. On confirm page, click Create expense.
6. Open the distance expense.
7. Click Distance and change to 0.
8. Click Rate and select another rate.

Expected Result:

Amount will be 0.00 because distance is 0.

Actual Result:

Amount changes to the value of previous distance (non-zero) when distance is 0.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022016105642631798329
• Upwork Job ID: 2016105642631798329
• Last Price Increase: 2026-03-11

Issue Owner

Current Issue Owner: @dukenv0307

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @johncschuster (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

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

[etCoderDysto]

BE issue

[yatin-italy]

🚨 Edited by proposal-police: This proposal was edited at 2026-01-27 13:25:27 UTC.

Proposal

Restate the problem this issue is trying to solve.

When editing a distance expense, if the user sets the distance to 0 and then changes the rate, the Amount updates back to a non-zero value. The Amount should stay 0.00 after the rate change.

What is the root cause of that problem?

The earliest wrong assumption is in src/libs/TransactionUtils/index.ts inside getUpdatedTransaction, where the code assumes the original transaction always has the correct distance value. This is wrong because the user may have already changed the distance to 0 in updatedTransaction. On line 616 the code reads distance from transaction instead of updatedTransaction, and on line 628 it reads distance using oldMileageRate?.unit instead of the new unit. This causes stale distance data to be used and recalculates a non-zero amount.

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

Update src/libs/TransactionUtils/index.ts to always read the current distance from updatedTransaction and use the new unit when recalculating the amount.

File: src/libs/TransactionUtils/index.ts

// Around line 613-618
// If the distanceUnit is set and the rate is changed to one that has a different unit, convert the distance to the new unit
if (existingDistanceUnit && newDistanceUnit !== existingDistanceUnit) {
    const conversionFactor = existingDistanceUnit === CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES ? CONST.CUSTOM_UNITS.MILES_TO_KILOMETERS : CONST.CUSTOM_UNITS.KILOMETERS_TO_MILES;
    // FIX: Use updatedTransaction instead of transaction to get the current distance value (including 0)
    const distance = roundToTwoDecimalPlaces((updatedTransaction?.comment?.customUnit?.quantity ?? 0) * conversionFactor);
    lodashSet(updatedTransaction, 'comment.customUnit.quantity', distance);
}

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 oldMileageRate = DistanceRequestUtils.getRate({transaction, policy});
    const updatedMileageRate = DistanceRequestUtils.getRate({transaction: updatedTransaction, policy, useTransactionDistanceUnit: false});
    const {unit, rate} = updatedMileageRate;
    // FIX: Use updatedTransaction with the NEW unit to get the current distance value (including 0)
    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;
    // eslint-disable-next-line @typescript-eslint/no-deprecated
    const updatedMerchant = DistanceRequestUtils.getDistanceMerchant(
        true,
        distanceInMeters,
        unit,
        rate,
        updatedCurrency,
        translateLocal,
        (digit) => toLocaleDigit(IntlStore.getCurrentLocale(), digit),
    );
    updatedTransaction.amount = updatedAmount;
    updatedTransaction.modifiedAmount = updatedAmount;
    updatedTransaction.modifiedMerchant = updatedMerchant;
    updatedTransaction.modifiedCurrency = updatedCurrency;
}

What alternative solutions did you explore? (Optional)

Adding a special case for distance equal to 0 was considered but not chosen because the real issue is using stale data instead of the updated transaction state.

[yatin-italy]

BE issue

@mananjadhav @johncschuster This is a frontend issue because the bug is in src/libs/TransactionUtils/index.ts, which is frontend TypeScript code that builds optimistic UI data before the API call. The UI shows the wrong amount due to an incorrect optimistic calculation, even though the backend may be correct. The fix is to update the frontend logic to use updatedTransaction instead of transaction.

[rohit9625]

Seems like a backend issue to me as well. Also, your solution doesn't work for me, @yatin-italy