[$250] Pay report dead-ends with generic error when cached report total is stale ("amount changed")

[MelvinBot]

Problem

When a payer clicks Pay on a report, the App sends the Onyx-cached report total it last rendered. If that cached total is even slightly stale (e.g. a few cents of drift after a currency exchange-rate re-conversion on a foreign-currency expense), it no longer matches the server-computed reimbursable total. The backend correctly rejects the payment with an "amount changed" error to prevent paying an amount the user didn't actually see and consent to.

The problem is what the App does next:

1. It shows a generic error — Unexpected error. Please try again later. (src/languages/en.ts:1536, via iou.error.other at src/libs/actions/IOU/PayMoneyRequest.ts:397).
2. Its failure data rolls Onyx back to the same stale report snapshot (src/libs/actions/IOU/PayMoneyRequest.ts:401-407).

So clicking Pay again sends the same stale total and hits the same wall. The user is stuck in a dead-end loop with no indication of what's wrong or how to recover. The only current workaround is to manually reload the report so the client picks up the corrected total — which a customer should never need to know to do.

The cached total is read here: src/libs/actions/IOU/PayMoneyRequest.ts:250-257.

Expected behavior

Clicking Pay should succeed (or self-recover) without the user needing to manually reload the report. The backend consent guardrail is correct and should stay — the fix is for the client to stop dead-ending on a stale total.

Actual behavior

Payment fails with a generic "Unexpected error. Please try again later." Retrying without a manual page reload reproduces the same error every time.

Proposed direction

Make the client auto-recover from a stale total instead of dead-ending. When PayMoneyRequest fails specifically because the displayed amount no longer matches the server total, the App should re-fetch the report to refresh the cached total, then re-confirm with the corrected amount (or silently retry within a trivial tolerance) — no manual reload required.

There is clean prior art for this shape: the Reauthentication middleware already intercepts a specific backend response code, transparently fixes the underlying state, and re-runs the original request. A "stale total" recovery should follow the same pattern.

Implementation notes

Three changes, in order of importance:

1. Auto-recover (core fix) — in PayMoneyRequest.ts, detect the "amount changed" failure, trigger an OpenReport/reconnect to pull the live total, then re-confirm and retry. Today the failure data blindly restores the same stale iouReport snapshot (lines 401-407), which guarantees the next attempt fails too.

2. Don't clobber a server-pushed total — confirm whether the failure response already includes a refreshed report.total in its onyxData. If it does, the generic failure path is overwriting it with the stale value; honoring it may largely resolve the issue on its own.

3. Meaningful error copy (fallback) — if auto-retry isn't pursued, at minimum replace the generic iou.error.other text with something actionable ("The amount on this report changed — review the new total and pay again"). This still requires user action, so it's the weakest option and shouldn't be the only change.

Scope sizing: a quick log query on how often PayMoneyRequest hits this "amount changed" rejection across all users (not just one report) would size the impact and confirm FX-rate timing is the dominant trigger.

Platform

Web (and any platform sharing this Onyx flow).

---

Originated from an internal Concierge escalation (Expensify/Expensify#648321). The backend guardrail is working as designed; this is a frontend recovery/UX defect in App.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022066759120306795731
• Upwork Job ID: 2066759120306795731
• Last Price Increase: 2026-06-16

[MelvinBot]

Proposal

What is the root cause of that problem?

When Pay is clicked, the App sends the Onyx-cached report total as the amount API parameter. If that cached total is stale (e.g. a few cents of FX re-conversion drift), the backend rejects the payment to protect the payer's consent — and the App then rolls Onyx back to the same stale snapshot, so every retry resends the identical stale amount and hits the same wall. There is no client-side recovery, so the user dead-ends until they manually reload the report.

Verified end-to-end against the code at the issue's SHA:

• The cached total is computed from iouReport.total (PayMoneyRequest.ts:250-253) and sent to the server as amount: Math.abs(total) (PayMoneyRequest.ts:505).
• On failure, failureData restores the same iouReport via {...iouReport} (PayMoneyRequest.ts:401-407) — this is what guarantees the next attempt fails too.
• The optimistic failure error is the generic iou.error.other (PayMoneyRequest.ts:397 → en.ts:1536).

One correction to the issue's premise — the user-facing error text

The issue states the user sees the generic "Unexpected error. Please try again later." But the directly-related user report #93538 shows a screenshot of "The requested amount has changed" — a server-provided message. Server response onyxData is applied on top of the optimistic data (SaveResponseInOnyx.ts:39), so the backend's specific message likely overrides the generic one in practice.

This doesn't change the root cause or the fix — the dead-end retry loop is real regardless of which string is shown. It just means "meaningful error copy" (implementation note #3) may already be partly handled by the server, making auto-recovery the only change that actually matters.

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

Make the client auto-recover from a stale total instead of restoring the stale snapshot:

1. Stop clobbering the live total on failure. The failure path at PayMoneyRequest.ts:401-407 blindly restores {...iouReport}. First confirm whether the failure response already carries a refreshed report.total in its onyxData; if so, the rollback is overwriting it and simply honoring the server value largely fixes the loop.
2. Detect the "amount changed" rejection and refresh, then re-confirm. Trigger an OpenReport/reconnect to pull the live total, then re-confirm the payment with the corrected amount. The Reauthentication middleware is clean prior art: it intercepts a specific backend code, fixes the underlying state, and replays the original request.
3. Keep the backend guardrail — it is working as designed; this is purely a frontend recovery defect.

What alternative solutions did you explore? (Optional)

Weakest fallback: only replace the generic copy with actionable text (e.g. "The amount on this report changed — review the new total and pay again"). This still forces a manual user action and, per the note above, the server may already surface a similar message — so it should not be the only change.

Related issues found

• [$250] Receiving "The requested amount has changed" error when trying to Pay a report #93538 — "Receiving 'The requested amount has changed' error when trying to Pay a report" — the customer-facing report of this exact bug (External, Help Wanted, Needs Reproduction).
• [$250] Web - IOU - No error shown to user A after requested amount changes by user B and A reconnects #87754 — "No error shown to user A after requested amount changes by user B and A reconnects" — adjacent amount-change-detection gap on the same Pay flow.

These should likely be cross-linked / deduped with this issue.

---

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

[ahmdshrif]

Proposal

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

Paying a report whose Onyx-cached total has drifted (e.g. a few cents after an FX re-conversion) is correctly rejected by the backend with "amount changed", but the App shows a generic error and rolls the report back to the same stale total — so every retry sends the same stale amount and hits the same wall, a dead-end until the user manually reloads.

What is the root cause of that problem?

The shared pay failure path in getPayMoneyRequestParams both masks the real error and clobbers the server's correction. Two coupled defects:

1. Generic copy hides the reason. failureData hardcodes iou.error.other → "Unexpected error" (en.ts#L1536), so the backend's specific "amount changed" message never reaches the user.
2. Stale snapshot re-pins the bad total (the loop). failureData MERGEs the whole pre-payment report back via {...iouReport}. It should only undo the optimistic fields it set (statusNum/stateNum/pendingFields/nextStep); spreading the whole report re-asserts the stale total. SaveResponseInOnyx applies both the server response and this failureData, so the wide spread overwrites any corrected total the server pushes on rejection. The next Pay re-sends amount: Math.abs(total) from the same stale total → identical rejection forever.

Both pay entry points inherit this — payMoneyRequest and payInvoice both build params via getPayMoneyRequestParams; cancelPayment/markReportPaymentReceived use separate onyxData and are unaffected. Defect 1 = generic copy, defect 2 = the infinite loop.

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

In getPayMoneyRequestParams failureData (L391-L407):

• Restore only the optimistically-changed report fields instead of {...iouReport}, so a server-corrected total survives the rollback:

value: {
    pendingFields: {preview: null, reimbursed: null, partial: null, nextStep: null},
    statusNum: iouReport?.statusNum, stateNum: iouReport?.stateNum, nextStep: currentNextStepDeprecated,
}

• Drop the hardcoded iou.error.other so the backend's specific message surfaces.

Regression safety: optimistic/success paths and the backend consent gate are untouched, so a normal pay failure still reverts exactly as today — only the over-wide stale restore is narrowed.

What alternative solutions did you explore? (Optional)

1. Reauthentication-style middleware: intercept the "amount changed" jsonCode, call openReport to pull the live total, then replay the request — mirroring Reauthentication.ts. Best UX and guaranteed correct if the server omits a corrected total on failure; larger surface — good as a follow-up on top of the fix above.
2. Only change the copy to "amount changed, review and pay again". Incomplete — defect 2 still re-pins the stale total, so retry keeps failing and the actionable message becomes a dead-end.

[lorretheboy]

Proposal

What is the root cause of that problem?

PayMoneyRequest sends the amount it computed from the Onyx-cached iouReport.total, not a live value:

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

Lines 250 to 253 in 7af4b0e

	let total = (iouReport?.total ?? 0) - (iouReport?.nonReimbursableTotal ?? 0);
	if (hasHeldExpensesReportUtils(reportTransactions) && !full && !!iouReport?.unheldTotal) {
	total = iouReport.unheldTotal - (iouReport?.unheldNonReimbursableTotal ?? 0);
	}

which becomes the amount param on the request:

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

Line 505 in 7af4b0e

amount: Math.abs(total),

If that cached total has drifted from the server's reimbursable total (e.g. FX re-conversion), the backend rejects with "amount changed". The request is sent through API.write (the write/sequential queue), and there is no handler that intercepts this rejection to refresh state and replay — unlike NOT_AUTHENTICATED, which the Reauthentication middleware catches, fixes, and re-runs:

App/src/libs/Middleware/Reauthentication.ts

Lines 97 to 114 in 7af4b0e

	return reauthenticate(request?.commandName)
	.then((wasSuccessful) => {
	if (!wasSuccessful) {
	return;
	}
	if (isFromSequentialQueue || apiRequestType === CONST.API_REQUEST_TYPE.MAKE_REQUEST_WITH_SIDE_EFFECTS) {
	return processWithMiddleware(request, isFromSequentialQueue);
	}
	if (apiRequestType === CONST.API_REQUEST_TYPE.READ) {
	// Re-sync app data after successful re-authentication
	reconnect();
	return Promise.resolve();
	}
	replayMainQueue(request);
	})

So the rejection falls through to the generic failure path. Two things then guarantee the dead-end: the error shown is iou.error.other:

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

Lines 391 to 399 in 7af4b0e

	onyxData.failureData?.push(
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${iouReport?.reportID}`,
	value: {
	[optimisticIOUReportAction.reportActionID]: {
	errors: getMicroSecondOnyxErrorWithTranslationKey('iou.error.other', 0),
	},
	},

and the failure data merges the entire stale iouReport back into Onyx, re-stamping the stale total (and overwriting any corrected total the server may have pushed):

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

Lines 401 to 407 in 7af4b0e

	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${iouReport?.reportID}`,
	value: {
	...iouReport,
	},
	},

Next click recomputes the same amount from the same stale total → same rejection. Loop.

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

1. Stop restoring the stale total on failure. The failure update should roll back only the fields the optimistic update changed (statusNum, stateNum, pendingFields, nextStep, etc.), not spread the whole iouReport. Leaving total alone lets a server-pushed corrected total survive the rollback here:

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

   Lines 401 to 407 in 7af4b0e

   	{
   	onyxMethod: Onyx.METHOD.MERGE,
   	key: `${ONYXKEYS.COLLECTION.REPORT}${iouReport?.reportID}`,
   	value: {
   	...iouReport,
   	},
   	},

   First confirm whether the "amount changed" response already returns a refreshed report.total in its onyxData; if so, this single change largely self-heals — the next Pay reads the corrected total.

2. Auto-recover (core fix). Have the backend tag the rejection with a distinct, detectable signal (a specific jsonCode/message rather than a generic 400). When PayMoneyRequest sees it, follow the Reauthentication shape: trigger OpenReport/reconnect to pull the live total, then re-confirm and replay the pay request with the corrected amount — no manual reload.

3. Actionable copy (fallback only). If auto-retry isn't pursued, replace iou.error.other with a specific string ("The amount on this report changed — review the new total and pay again"):

   App/src/languages/en.ts

   Line 1536 in 7af4b0e

   other: 'Unexpected error. Please try again later.',

   This still forces user action, so it's the weakest option.

What alternative solutions did you explore? (Optional)

Re-read the live iouReport.total immediately before building params at the point above, so a freshly synced total is used even without dedicated recovery. This narrows but doesn't close the race (the total can still drift between read and server processing), so the failure-rollback fix in change #1 is still needed as the backstop.

[melvin-bot]

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

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

There are two cooperating mechanisms that turn a benign stale total into a permanent dead-end.

1. The amount we send for consent is read from the Onyx cache at click time. In getPayMoneyRequestParams the total is derived from the cached iouReport.total and sent verbatim as amount:

• total computed from cache:

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

  Lines 250 to 253 in 7af4b0e

  	let total = (iouReport?.total ?? 0) - (iouReport?.nonReimbursableTotal ?? 0);
  	if (hasHeldExpensesReportUtils(reportTransactions) && !full && !!iouReport?.unheldTotal) {
  	total = iouReport.unheldTotal - (iouReport?.unheldNonReimbursableTotal ?? 0);
  	}

• sent as the amount param:

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

  Line 505 in 7af4b0e

  amount: Math.abs(total),

When an FX re-conversion drifts the cached total a few cents off the server-computed reimbursable total, the backend consent guardrail correctly rejects with "amount changed". That guardrail is right and should stay.

2. The failure path restores the entire stale snapshot, so the cache never self-corrects. On failure we merge {...iouReport} — the whole cached report, including the stale total — back into Onyx, and surface the generic iou.error.other:

• restores the stale report wholesale:

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

  Lines 401 to 407 in 7af4b0e

  	{
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.REPORT}${iouReport?.reportID}`,
  	value: {
  	...iouReport,
  	},
  	},

• generic error:

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

  Lines 391 to 400 in 7af4b0e

  	onyxData.failureData?.push(
  	{
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${iouReport?.reportID}`,
  	value: {
  	[optimisticIOUReportAction.reportActionID]: {
  	errors: getMicroSecondOnyxErrorWithTranslationKey('iou.error.other', 0),
  	},
  	},
  	},

  (key at

  App/src/languages/en.ts

  Line 1536 in 7af4b0e

  other: 'Unexpected error. Please try again later.',

  )

Because the value: {...iouReport} merge spreads back the old total, it overwrites any corrected total the server may push in its own failure onyxData. So the cache stays stale, the next Pay click recomputes the same amount from it, and the same rejection fires forever — until a manual reload re-fetches the live total. That blind full-snapshot restore is the root cause of the loop; sending a cached amount is what triggers it.

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

Primary — stop clobbering the corrected total, then refresh so the cache self-heals.

The failure rollback only needs to undo the optimistic mutations (status/state/pending fields), not restore the whole report. Narrow it so it never re-writes total:

// failureData for the iouReport — roll back only what the optimistic update changed,
// do NOT spread {...iouReport} (that re-writes a possibly stale total).
{
    onyxMethod: Onyx.METHOD.MERGE,
    key: `${ONYXKEYS.COLLECTION.REPORT}${iouReport?.reportID}`,
    value: {
        statusNum: iouReport?.statusNum,
        stateNum: iouReport?.stateNum,
        hasOutstandingChildRequest: iouReport?.hasOutstandingChildRequest,
        pendingFields: {preview: null, reimbursed: null, partial: null, nextStep: null},
        errors: getMicroSecondOnyxErrorWithTranslationKey('iou.error.amountChanged', 0),
    },
}

With total no longer overwritten, a server-corrected total in the failure response survives. To guarantee recovery even when the failure response carries no fresh total, refresh the report on this failure so the next attempt recomputes a correct amount with no manual reload — call openReport(iouReport.reportID) (i.e. a reconnect for that report) from the PayMoneyRequest failure handling. This mirrors the established Reauthentication middleware shape — intercept a specific backend signal, transparently fix the underlying state, then let the request be retried (

App/src/libs/Middleware/Reauthentication.ts

Lines 97 to 122 in 7af4b0e

	return reauthenticate(request?.commandName)
	.then((wasSuccessful) => {
	if (!wasSuccessful) {
	return;
	}
	if (isFromSequentialQueue || apiRequestType === CONST.API_REQUEST_TYPE.MAKE_REQUEST_WITH_SIDE_EFFECTS) {
	return processWithMiddleware(request, isFromSequentialQueue);
	}
	if (apiRequestType === CONST.API_REQUEST_TYPE.READ) {
	// Re-sync app data after successful re-authentication
	reconnect();
	return Promise.resolve();
	}
	replayMainQueue(request);
	})
	.catch(() => {
	if (isFromSequentialQueue || apiRequestType) {
	throw new Error('Failed to reauthenticate');
	}
	// If we make it here, then our reauthenticate request could not be made due to a networking issue. The original request can be retried safely.
	replayMainQueue(request);
	});

).

Additionally, replace the generic iou.error.other with an actionable key (e.g. iou.error.amountChanged → "The amount on this report changed — review the new total and pay again") so the user understands the one-time prompt while the total refreshes.

Note: detecting this specific rejection cleanly requires a stable backend signal — confirm whether Auth returns a dedicated jsonCode/error string for "amount changed". If so, the refresh+message should be gated on it; if not, narrowing the rollback (above) plus honoring any server-pushed total already breaks the loop on its own.

What alternative solutions did you explore? (Optional)

• Fully transparent middleware retry. Add a dedicated middleware keyed off the "amount changed" jsonCode that, like Reauthentication, runs OpenReport to pull the live total and then replays the original PayMoneyRequest automatically — zero user interaction. Cleanest long-term, but depends on a stable backend code and on it being safe to silently re-pay a server-corrected amount within a tolerance (consent implications), so it needs backend buy-in.
• Error-copy-only fix. Just swap iou.error.other for an actionable message. Minimal, but the user must still know to manually reload, so it leaves the dead-end intact — weakest option, not sufficient alone.

[x-dev90]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-16 10:17:35 UTC.

Proposal

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

When paying an approved report, the backend can reject PayMoneyRequest with The requested amount has changed if the amount sent by the client does not match the backend-calculated report total.

After this happens, the app has two problems:

1. The report total can remain stale in Onyx, so pressing Pay again can send the same stale amount.
2. After the user pays successfully with the refreshed amount, the report card can still show the old The requested amount has changed error because the failed optimistic IOU action keeps its error.

What is the root cause of that problem?

PayMoneyRequest calculates the payment amount from the report currently cached in Onyx:

src/libs/actions/IOU/PayMoneyRequest.ts

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

Lines 249 to 253 in fda079c

	const reportTransactions = getReportTransactions(iouReport?.reportID);
	let total = (iouReport?.total ?? 0) - (iouReport?.nonReimbursableTotal ?? 0);
	if (hasHeldExpensesReportUtils(reportTransactions) && !full && !!iouReport?.unheldTotal) {
	total = iouReport.unheldTotal - (iouReport?.unheldNonReimbursableTotal ?? 0);
	}

That amount is then sent to the backend:

src/libs/actions/IOU/PayMoneyRequest.ts

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

Lines 836 to 844 in fda079c

	// For now, we need to call the PayMoneyRequestWithWallet API since PayMoneyRequest was not updated to work with
	// Expensify Wallets.
	const apiCommand = paymentType === CONST.IOU.PAYMENT_TYPE.EXPENSIFY ? WRITE_COMMANDS.PAY_MONEY_REQUEST_WITH_WALLET : WRITE_COMMANDS.PAY_MONEY_REQUEST;
	onPaid?.();
	if (shouldPlaySuccessSound) {
	playSound(SOUNDS.SUCCESS);
	}
	API.write(apiCommand, payMoneyRequestParams, mergeAdditionalPayOnyxData(onyxData, additionalOnyxData));

If the cached total is stale, the backend correctly rejects the request with jsonCode: 666 and The requested amount has changed. The current response middleware applies the error response but does not refresh the report, so the stale total can stay in Onyx:

src/libs/Middleware/SaveResponseInOnyx.ts

App/src/libs/Middleware/SaveResponseInOnyx.ts

Lines 20 to 40 in fda079c

	const SaveResponseInOnyx: Middleware = <TKey extends OnyxKey>(requestResponse: Promise<Response<TKey> | void>, request: OnyxRequest<TKey>) =>
	requestResponse.then((response = {}) => {
	const onyxUpdates = response?.onyxData ?? [];
	// Sometimes we call requests that are successful but they don't have any response or any success/failure/finally data to set. Let's return early since
	// we don't need to store anything here.
	if (!onyxUpdates && !request.successData && !request.failureData && !request.finallyData) {
	return Promise.resolve(response);
	}
	const responseToApply: OnyxUpdatesFromServer<TKey> = {
	type: CONST.ONYX_UPDATE_TYPES.HTTPS,
	lastUpdateID: Number(response?.lastUpdateID ?? CONST.DEFAULT_NUMBER_ID),
	previousUpdateID: Number(response?.previousUpdateID ?? CONST.DEFAULT_NUMBER_ID),
	request,
	response: response ?? {},
	};
	if (requestsToIgnoreLastUpdateID.has(request.command) || !OnyxUpdates.doesClientNeedToBeUpdated({previousUpdateID: Number(response?.previousUpdateID ?? CONST.DEFAULT_NUMBER_ID)})) {
	return OnyxUpdates.apply(responseToApply);
	}

During testing, the next issue was also confirmed: the failed optimistic IOU pay action keeps the backend error in reportActions_<reportID>. Report cards aggregate report action errors into the report error state:

src/libs/ReportUtils.ts

App/src/libs/ReportUtils.ts

Lines 9089 to 9162 in fda079c

	function getAllReportActionsErrorsAndReportActionThatRequiresAttention(
	report: OnyxEntry<Report>,
	reportActions: OnyxEntry<ReportActions>,
	allTransactions: OnyxCollection<Transaction>,
	isReportArchived = false,
	reports?: OnyxCollection<Report>,
	): ReportErrorsAndReportActionThatRequiresAttention {
	const reportActionsArray = Object.values(reportActions ?? {}).filter((action) => !isDeletedAction(action));
	const reportActionErrors: ErrorFields = {};
	let reportAction: OnyxEntry<ReportAction>;
	for (const action of reportActionsArray) {
	if (action && !isEmptyValueObject(action.errors)) {
	Object.assign(reportActionErrors, action.errors);
	if (!reportAction) {
	reportAction = action;
	}
	}
	}
	if (!isReportArchived && hasSmartscanError(reportActionsArray, report, allTransactions, reports)) {
	reportActionErrors.smartscan = getMicroSecondOnyxErrorWithTranslationKey('iou.error.genericSmartscanFailureMessage');
	reportAction = getReportActionWithSmartscanError(reportActionsArray, report, allTransactions, reports);
	}
	if (!isReportArchived && isReportOwner(report) && report?.statusNum === CONST.REPORT.STATUS_NUM.OPEN) {
	const mostRecentActiveDEWAction = getMostRecentActiveDEWSubmitFailedAction(reportActionsArray);
	if (mostRecentActiveDEWAction) {
	reportActionErrors.dewSubmitFailed = getMicroSecondOnyxErrorWithTranslationKey('iou.error.genericCreateFailureMessage');
	reportAction = mostRecentActiveDEWAction;
	}
	}
	return {
	errors: reportActionErrors,
	reportAction,
	};
	}
	/**
	* Get an object of error messages keyed by microtime by combining all error objects related to the report.
	*/
	function getAllReportErrors(
	report: OnyxEntry<Report>,
	reportActions: OnyxEntry<ReportActions>,
	allTransactions: OnyxCollection<Transaction>,
	isReportArchived = false,
	reports?: OnyxCollection<Report>,
	): Errors {
	const reportErrorFields = report?.errorFields ?? {};
	const {errors: reportActionErrors} = getAllReportActionsErrorsAndReportActionThatRequiresAttention(report, reportActions, allTransactions, isReportArchived, reports);
	// All error objects related to the report. Each object in the sources contains error messages keyed by microtime
	const errorSources = {
	...reportErrorFields,
	...reportActionErrors,
	};
	const reportPolicy = allPolicies?.[`${ONYXKEYS.COLLECTION.POLICY}${report?.policyID}`];
	if (reportErrorFields.export && !getConnectedIntegration(reportPolicy)) {
	delete errorSources.export;
	}
	// Combine all error messages keyed by microtime into one object
	const errorSourcesArray = Object.values(errorSources ?? {});
	const allReportErrors = {};
	for (const errors of errorSourcesArray) {
	if (!isEmptyObject(errors)) {
	Object.assign(allReportErrors, errors);
	}
	}
	return allReportErrors;

So even after a later Pay succeeds, the old failed action can still make the report card show The requested amount has changed.

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

We should handle this as a targeted recovery for this exact backend guardrail.

First, when PayMoneyRequest or PayMoneyRequestWithWallet returns jsonCode: 666 with The requested amount has changed, call the existing openReport action for the failed iouReportID. This refreshes the report through the normal report-loading path and gets the latest server total before the user tries to pay again.

This should be added in the shared response middleware:

src/libs/Middleware/SaveResponseInOnyx.ts

App/src/libs/Middleware/SaveResponseInOnyx.ts

Lines 20 to 40 in fda079c

	const SaveResponseInOnyx: Middleware = <TKey extends OnyxKey>(requestResponse: Promise<Response<TKey> | void>, request: OnyxRequest<TKey>) =>
	requestResponse.then((response = {}) => {
	const onyxUpdates = response?.onyxData ?? [];
	// Sometimes we call requests that are successful but they don't have any response or any success/failure/finally data to set. Let's return early since
	// we don't need to store anything here.
	if (!onyxUpdates && !request.successData && !request.failureData && !request.finallyData) {
	return Promise.resolve(response);
	}
	const responseToApply: OnyxUpdatesFromServer<TKey> = {
	type: CONST.ONYX_UPDATE_TYPES.HTTPS,
	lastUpdateID: Number(response?.lastUpdateID ?? CONST.DEFAULT_NUMBER_ID),
	previousUpdateID: Number(response?.previousUpdateID ?? CONST.DEFAULT_NUMBER_ID),
	request,
	response: response ?? {},
	};
	if (requestsToIgnoreLastUpdateID.has(request.command) || !OnyxUpdates.doesClientNeedToBeUpdated({previousUpdateID: Number(response?.previousUpdateID ?? CONST.DEFAULT_NUMBER_ID)})) {
	return OnyxUpdates.apply(responseToApply);
	}

Second, when a later Pay succeeds for that same report, clear old IOU report action errors that exactly match The requested amount has changed. This removes stale failed-pay errors from previous attempts, so the report card no longer shows the old error after the expense is paid successfully.

This should be added to the Pay success cleanup in PayMoneyRequest, where we already clear the successful optimistic pay action pending state:

src/libs/actions/IOU/PayMoneyRequest.ts

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

Lines 943 to 966 in fda079c

	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${iouReport.reportID}`,
	value: {
	pendingFields: {
	preview: null,
	reimbursed: null,
	partial: null,
	nextStep: null,
	},
	errors: null,
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${iouReport.reportID}`,
	value: {
	[optimisticIOUReportAction.reportActionID]: {
	pendingAction: null,
	},
	},
	},
	];

In plain English, the fix is:

• Do not retry payment automatically.
• Let the backend rejection stay visible to the user.
• Refresh the report so the next Pay uses the latest total.
• After a successful Pay, remove only stale IOU action errors with the exact amount-changed message.

This is safer than auto-paying after refresh because the amount changed from what the user originally confirmed. It also keeps the cleanup narrow and avoids touching unrelated report errors.

Video demo of fix:

loop-issue-fix.mov

What alternative solutions did you explore? (Optional)

Alternative 1:

Add a separate middleware only for this Pay amount-changed recovery. This works, but it adds a new middleware and registration for a narrow case. Updating SaveResponseInOnyx is smaller because every API response already goes through that middleware.

Alternative 2:

Only change failureData in PayMoneyRequest so it does not restore a stale report snapshot. This is not enough because the backend error response does not include the corrected report total, so the client still needs an OpenReport refresh.

Alternative 3:

Automatically retry the Pay after refreshing the report. I rejected this because the backend is telling us the amount changed. The user should see the refreshed amount and explicitly press Pay again.

[melvin-bot]

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

[github-actions]

⚠️ @x-dev90 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.

[github-actions]

⚠️ @lorretheboy Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).