[$250] Track distance- Distance and rate fields are incorrect when submitting expense in offline mode

[IuliiaHerets]

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.1.8-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: Exp
Email or phone of affected tester (no customers): applausetester+069485rw@applause.expensifail.com
Issue reported by: Applause Internal Team
Device used: Mac 15.3 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Account has self DM.
• There is at least one workspace.
• Workspace distance rate unit (miles) is different from personal distance rate unit (kilometers).

1. Go to staging.new.expensify.com
2. Go to self DM.
3. Track a distance expense in self DM.
4. Go offline.
5. Click Submit it to someone.
6. Select a workspace.
7. On confirmation page, click Rate and select a distance rate from the workspace.
8. Note that the distance field does not update to the correct value except the distance unit has changed.
9. Submit the expense to the workspace chat.
10. Go to transaction thread.
11. Note that Rate field does not show the rate that is selected in Step 7.

Expected Result:

In Step 8, the distance field will show pending if the unit conversion cannot be done in offline mode.
In Step 11, Rate field should show the same rate that is selected on the confirmation page in Step 7.

Actual Result:

In Step 8, the distance field shows the same value with updated unit.
In Step 11, Rate field does not show the same rate that is selected on the confirmation page in Step 7.

Workaround:

Unknown

Platforms:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6760595_1741066500182.20250304_132702.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021897027679526781763
• Upwork Job ID: 1897027679526781763
• Last Price Increase: 2025-03-04
• Automatic offers:
• nkdengineer | Contributor | 106427453

Issue Owner

Current Issue Owner: @sobitneupane

[melvin-bot]

Triggered auto assignment to @isabelastisser (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.

[nkdengineer]

🚨 Edited by proposal-police: This proposal was edited at 2025-03-04 10:30:52 UTC.

Proposal

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

Rate field does not show the same rate that is selected on the confirmation page in Step 7.

What is the root cause of that problem?

1. When we submit a tracked expense to the workspace, requestMoney is called. And we used existingTransaction from the transaction data. But the change we made is saved in the transaction draft data in the case we submit a tracked expense.

Then the custom unit after we submit it is the P2P custom unit and the MoneyRequestView displays the wrong rate and distance.

App/src/libs/actions/IOU.ts

Line 4593 in b649380

const existingTransaction = allTransactions[`${ONYXKEYS.COLLECTION.TRANSACTION}${existingTransactionID}`];

2. For the wrong distance, when we offline, the route doesn't exist in the transaction, then we get the distance in meters based on the quantity of customUnit. The quantity in the route data is the value in the meter unit then if we online the distance is correct when we update the distance rate.

App/src/libs/TransactionUtils/getDistanceInMeters.ts

Lines 7 to 20 in 7009fe8

	function getDistanceInMeters(transaction: OnyxInputOrEntry<Transaction>, unit: Unit | undefined) {
	// If we are creating a new distance request, the distance is available in routes.route0.distance and it's already in meters.
	if (transaction?.routes?.route0?.distance) {
	return transaction.routes.route0.distance;
	}
	// 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.
	if (transaction?.comment?.customUnit?.quantity && unit) {
	return DistanceRequestUtils.convertToDistanceInMeters(transaction.comment.customUnit.quantity, unit);
	}
	return 0;
	}

But, the quantity of the customUnit is the distance of the current unit. And then if the unit of the workspace is different from the unit of P2P distance, the distance will be displayed wrong because we don't change the quantity here when the unit is changed.

App/src/libs/actions/IOU.ts

Lines 1062 to 1073 in 7009fe8

	Onyx.merge(`${isDraft ? ONYXKEYS.COLLECTION.TRANSACTION_DRAFT : ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`, {
	comment: {
	customUnit: {
	customUnitRateID,
	...(!!policy && {defaultP2PRate: null}),
	...(distanceRate && {distanceUnit: distanceRate.unit}),
	},
	},
	});
	}
	/** Helper function to get the receipt error for expenses, or the generic error if there's no receipt */

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

1. If the action is submit, we should get the data from the transaction draft and use it as existingTransaction.

const existingTransaction = (action === CONST.IOU.ACTION.SUBMIT) ? allTransactionDrafts[`${ONYXKEYS.COLLECTION.TRANSACTION_DRAFT}${existingTransactionID}`] : allTransactions[`${ONYXKEYS.COLLECTION.TRANSACTION}${existingTransactionID}`];

App/src/libs/actions/IOU.ts

Line 4593 in b649380

const existingTransaction = allTransactions[`${ONYXKEYS.COLLECTION.TRANSACTION}${existingTransactionID}`];

2. When we update the custom unit here we should update the quantity if the distance unit is changed

const transaction = isDraft ? allTransactionDrafts[`${ONYXKEYS.COLLECTION.TRANSACTION_DRAFT}${transactionID}`] : allTransactions[`${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`];
let newDistance;
if (distanceRate?.unit && distanceRate?.unit !== transaction?.comment?.customUnit?.distanceUnit) {
    newDistance = DistanceRequestUtils.convertDistanceUnit(getDistanceInMeters(transaction, transaction?.comment?.customUnit?.distanceUnit), distanceRate.unit);
}
Onyx.merge(`${isDraft ? ONYXKEYS.COLLECTION.TRANSACTION_DRAFT : ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`, {
    comment: {
        customUnit: {
            customUnitRateID,
            ...(!!policy && {defaultP2PRate: null}),
            ...(distanceRate && {distanceUnit: distanceRate.unit}),
            ...(newDistance && {quantity: newDistance}),
        },
    },
});

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Test requestMoney function with the case action is submit and transaction is distance request. Verify that the customUnitRateID of the transaction is correct.

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.

[melvin-bot]

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

[melvin-bot]

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

[sobitneupane]

Thanks @nkdengineer

Even with the change you suggested, the distance field doesn't show the correct value.

const existingTransaction = allTransactions[${ONYXKEYS.COLLECTION.TRANSACTION}${existingTransactionID}];

@nkdengineer Could you please link the PR which introduced this piece of code?

[nkdengineer]

Even with the change you suggested, the distance field doesn't show the correct value.

@sobitneupane I updated the proposal with the RCA and solution for the distance

Screen.Recording.2025-03-06.at.23.45.01.mov

@nkdengineer Could you please link the PR which introduced this piece of code?

This feature existed from here

The code I mentioned was implemented here

[sobitneupane]

Thanks for the update @nkdengineer.

Proposal from @nkdengineer looks good to me.

🎀 👀 🎀 C+ reviewed