[Due for payment 2026-04-02] [$250] Track distance - Amount and Rate are not greyed out after editing in offline mode

[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: v9.3.31-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: #83393
Email or phone of affected tester (no customers): applausetester+ag040326@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11/ Chrome, iPhone 13 Mini/ iOS 26.3
App Component: Money Requests

Action Performed:

Preconditions: Workspace has distance rates enabled.
Have at least two distance rates.
In a workspace, have a distance expense with the distance rate A selected.

1. Open the Expensify app
2. Go to workspace settings > Distance rates
3. Edit the rate of the distance rate A
4. Go to the expense details with the distance rate A
5. Go offline
6. Change the Rate to any other
7. Note that the Amount and Rate have been updated but not greyed out
8. Change the Rate back to the distance rate A
9. Note that the Amount and Rate have been updated again, but they are still not greyed out, and the violation remains
10. Go online

Expected Result:

In step 7, the Amount and the Rate are greyed out.
In step 9, the Amount and the Rate are still greyed out, and the violation clears.

Actual Result:

In step 7, the Amount and Rate have been updated, but they are not greyed out despite being edited.
In step 9, the Amount and the Rate are still not greyed out, and the violation remains despite no longer having any difference between the amount and the calculated distance.
The violation is cleared after going online.

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

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022029468199571055503
• Upwork Job ID: 2029468199571055503
• Last Price Increase: 2026-03-12

[melvin-bot]

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

[MelvinBot]

Proposal

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

When editing the distance rate on a distance expense while offline, the Amount and Rate fields are not greyed out (pending indicator missing). Additionally, if the rate is changed back to the original, the modifiedAmount violation is not cleared until the device goes back online.

What is the root cause of that problem?

There are two separate root causes:

1. Missing pendingFields for customUnitRateID changes

When a user changes the distance rate, updateMoneyRequestDistanceRate() creates transactionChanges = {customUnitRateID: rateID} (IOU/index.ts:5898-5902). This calls getUpdatedTransaction(), which correctly recalculates amount, modifiedAmount, modifiedMerchant, and modifiedCurrency based on the new rate (TransactionUtils/index.ts:754-801).

However, the pendingFields computation at TransactionUtils/index.ts:906-928 only sets pending flags for keys explicitly present in transactionChanges. There is no case for customUnitRateID, so pendingFields ends up with no new entries. Compare this with the distance key at lines 921-925, which correctly maps to {amount, merchant, quantity} pending fields — the same pattern is missing for customUnitRateID.

Because the transaction's pendingFields never includes customUnitRateID, amount, merchant, or currency, the getPendingFieldAction() calls in MoneyRequestView.tsx return undefined, and OfflineWithFeedback does not apply the greyed-out opacity.

The same issue exists in getClearedPendingFields() at TransactionUtils/index.ts:637-659, which also lacks a customUnitRateID case for clearing the derived pending fields on success/failure.

2. modifiedAmount (distance) violation not cleared optimistically

The modifiedAmount violation with type: 'distance' ("Amount differs from calculated distance") is only generated and cleared by the server. It is completely absent from the client-side ViolationsUtils.getViolationsOnyxData() function (ViolationsUtils.ts:399-412).

In getUpdateMoneyRequestParams() at IOU/index.ts:4916-4942, the current violations are fetched and passed to getViolationsOnyxData(). The filtering at lines 4918-4921 only removes DUPLICATED_TRANSACTION when amount/date/currency change — there is no filter for modifiedAmount when hasModifiedDistanceRate is true. So the stale modifiedAmount violation persists in the optimistic data until the server responds.

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

Fix 1 — Add customUnitRateID to pendingFields and getClearedPendingFields:

In getUpdatedTransaction() at src/libs/TransactionUtils/index.ts:906-928, add a case for customUnitRateID that also marks amount, merchant, and currency as pending (since those values are recalculated when the rate changes):

...(Object.hasOwn(transactionChanges, 'customUnitRateID') && {
    customUnitRateID: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
    amount: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
    merchant: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
    currency: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
}),

And the corresponding case in getClearedPendingFields() at src/libs/TransactionUtils/index.ts:637-659:

...(Object.hasOwn(transactionChanges, 'customUnitRateID') && {
    customUnitRateID: null,
    amount: null,
    merchant: null,
    currency: null,
}),

Fix 2 — Clear stale modifiedAmount (distance) violation optimistically:

In getUpdateMoneyRequestParams() at src/libs/actions/IOU/index.ts, after the existing violation filtering (around line 4921), add a filter to remove the modifiedAmount violation with distance type when the distance rate is being changed (since the amount is being recalculated to match the new rate):

optimisticViolations = hasModifiedDistanceRate
    ? optimisticViolations.filter(
        (violation) => !(violation.name === CONST.VIOLATIONS.MODIFIED_AMOUNT && violation.data?.type === 'distance')
      )
    : optimisticViolations;

What alternative solutions did you explore? (Optional)

For the pending fields issue, an alternative would be to modify updateMoneyRequestDistanceRate() to explicitly include amount, merchant, and currency in transactionChanges. However, this is less maintainable because it couples the action to internal knowledge of derived field updates, and the pattern of mapping derived fields in getUpdatedTransaction() already exists for the distance key.

For the violation issue, an alternative would be to add modifiedAmount handling to ViolationsUtils.getViolationsOnyxData() (checking if the recalculated distance amount matches the transaction amount). This would be more robust but more complex, and filtering the stale violation during rate changes is sufficient since the server will reconcile the final state.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

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

[melvin-bot]

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

[twilight2294]

Proposal

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

When editing the distance rate on a distance expense while offline, the Amount and Rate fields are not greyed out to indicate pending status. Additionally, when the rate is changed back to the original value, the modifiedAmount violation persists until the device goes back online.

What is the root cause of that problem?

The getUpdateMoneyRequestParams() function in IOU/index.ts calculates pendingFields from the transactionChanges on line 4538, but fails to include them in the optimistic transaction update at lines 4742-4750.

The UI components in MoneyRequestView call getPendingFieldAction() to check transaction.pendingFields for each field (line 415, 823 for Amount, line 644 for Rate). The OfflineWithFeedback component then uses this pending action to determine whether to apply the greyed-out opacity effect. Without pendingFields in the transaction, getPendingFieldAction() returns undefined, so the opacity is never applied.

In contrast, the similar getUpdateTrackExpenseParams() function in the same file correctly includes pendingFields in its optimistic transaction update at line 5190, which is why track expenses work correctly but workspace expenses do not.

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

In IOU/index.ts, add pendingFields to the optimistic transaction update in getUpdateMoneyRequestParams():

optimisticData.push({
    onyxMethod: Onyx.METHOD.MERGE,
    key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`,
    value: {
        ...updatedTransaction,
        pendingFields,  // Add this line
        errorFields: null,
        reportID: newTransactionReportID ?? updatedTransaction?.reportID,
    },
});

This matches the pattern already used in getUpdateTrackExpenseParams() and ensures the UI can properly detect pending fields to apply the greyed-out state.

What alternative solutions did you explore? (Optional)

The existing MelvinBot proposal suggests modifying TransactionUtils to add customUnitRateID handling to pendingFields computation and clearing modifiedAmount violations optimistically. While that approach would work, it's more complex and modifies multiple functions. This solution is simpler and more targeted — the pendingFields are already being calculated correctly on line 4538; they just need to be included in the optimistic data. This single-line fix directly addresses the root cause without changing the violation handling logic or requiring modifications to multiple utility functions.

[abbasifaizan70]

Proposal

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

When editing a distance expense offline after its selected workspace distance rate has changed:

• changing the rate updates Amount and Rate, but these fields are not shown as pending (not greyed out),
• changing the rate back to the original rate updates values again, but the distance mismatch violation remains until reconnect.

Expected behavior is:

• Amount and Rate should remain greyed out while the offline update is pending sync, and
• if the user switches back to a rate that resolves the mismatch, the violation should clear immediately offline.

What is the root cause of that problem?

The UI pending state for Amount and Rate depends on transaction pendingFields.

App/src/components/ReportActionItem/MoneyRequestView.tsx

Line 414 in 375ad05

const getPendingFieldAction = (fieldPath: TransactionPendingFieldsKey) => (pendingAction ? undefined : transaction?.pendingFields?.[fieldPath]);

App/src/components/ReportActionItem/MoneyRequestView.tsx

Line 643 in 375ad05

<OfflineWithFeedback pendingAction={getPendingFieldAction('customUnitRateID')}>

App/src/components/ReportActionItem/MoneyRequestView.tsx

Line 821 in 375ad05

<OfflineWithFeedback pendingAction={getPendingFieldAction('amount') ?? (amountTitle ? getPendingFieldAction('customUnitRateID') : undefined)}>

In getUpdateMoneyRequestParams, pending fields are computed but not merged into the optimistic transaction update for this path, so edited fields can update without entering pending/greyed state.

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

Lines 4529 to 4531 in 375ad05

	const pendingFields: OnyxTypes.Transaction['pendingFields'] = Object.fromEntries(Object.keys(transactionChanges).map((key) => [key, CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE]));
	const clearedPendingFields = getClearedPendingFields(transactionChanges);
	const errorFields = Object.fromEntries(Object.keys(pendingFields).map((key) => [key, getMicroSecondOnyxErrorWithTranslationKey('iou.error.genericEditFailureMessage')]));

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

Lines 4733 to 4741 in 375ad05

	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`,
	value: {
	...updatedTransaction,
	errorFields: null,
	reportID: newTransactionReportID ?? updatedTransaction?.reportID,
	},
	});

For violations, optimistic filtering removes some stale violations (like noRoute) but does not remove stale distance modifiedAmount violations before recalculation, so the mismatch violation can persist locally until reconnect/server sync.

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

Lines 4918 to 4928 in 375ad05

	let optimisticViolations =
	hasModifiedAmount || hasModifiedDate || hasModifiedCurrency
	? currentTransactionViolations.filter((violation) => violation.name !== CONST.VIOLATIONS.DUPLICATED_TRANSACTION)
	: currentTransactionViolations;
	optimisticViolations =
	hasModifiedCategory && transactionChanges.category === ''
	? optimisticViolations.filter((violation) => violation.name !== CONST.VIOLATIONS.CATEGORY_OUT_OF_POLICY)
	: optimisticViolations;
	if (hasPendingWaypoints) {
	optimisticViolations = optimisticViolations.filter((violation) => violation.name !== CONST.VIOLATIONS.NO_ROUTE);
	}

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

Lines 4930 to 4943 in 375ad05

	const violationsOnyxData = ViolationsUtils.getViolationsOnyxData(
	updatedTransaction,
	optimisticViolations,
	policy,
	policyTagList ?? {},
	policyCategories ?? {},
	hasDependentTags(policy, policyTagList ?? {}),
	isInvoice,
	isSelfDM(iouReport),
	iouReport,
	isFromExpenseReport,
	);
	optimisticData.push(violationsOnyxData);
	failureData.push({

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

Persist pendingFields on the optimistic transaction merge in getUpdateMoneyRequestParams, so Amount and Rate reflect the pending offline state immediately.

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

Lines 4733 to 4741 in 375ad05

	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`,
	value: {
	...updatedTransaction,
	errorFields: null,
	reportID: newTransactionReportID ?? updatedTransaction?.reportID,
	},
	});

optimisticData.push({
    onyxMethod: Onyx.METHOD.MERGE,
    key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`,
    value: {
        ...updatedTransaction,
        pendingFields,
        errorFields: null,
        reportID: newTransactionReportID ?? updatedTransaction?.reportID,
    },
});

Before recomputing violations, remove stale distance modifiedAmount violation entries when distance-related edits occur (customUnitRateID, distance, or pending waypoints flow), so switching back to the original valid rate clears the violation immediately offline.

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

Lines 4918 to 4928 in 375ad05

	let optimisticViolations =
	hasModifiedAmount || hasModifiedDate || hasModifiedCurrency
	? currentTransactionViolations.filter((violation) => violation.name !== CONST.VIOLATIONS.DUPLICATED_TRANSACTION)
	: currentTransactionViolations;
	optimisticViolations =
	hasModifiedCategory && transactionChanges.category === ''
	? optimisticViolations.filter((violation) => violation.name !== CONST.VIOLATIONS.CATEGORY_OUT_OF_POLICY)
	: optimisticViolations;
	if (hasPendingWaypoints) {
	optimisticViolations = optimisticViolations.filter((violation) => violation.name !== CONST.VIOLATIONS.NO_ROUTE);
	}

const hasModifiedDistance = 'distance' in transactionChanges;
if (hasModifiedDistanceRate || hasModifiedDistance || hasPendingWaypoints) {
    optimisticViolations = optimisticViolations.filter(
        (violation) => !(violation.name === CONST.VIOLATIONS.MODIFIED_AMOUNT && violation.data?.type === CONST.MODIFIED_AMOUNT_VIOLATION_DATA.DISTANCE),
    );
}

[github-actions]

⚠️ @abbasifaizan70 Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.