[$250] Web - IOU - No error shown to user A after requested amount changes by user B and A reconnects

[vincdargento]

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.58-7
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://github.com/Expensify/Expensify/issues/379640
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11/Chrome
App Component: Chat Report View

Action Performed:

1. User A invites User B to the Free workspace
2. User B submits an expense
3. User A goes offline
4. User A taps ‘Pay’ on the original expense
5. User B edits the expense amount OR adds an additional expense while User A is offline
6. User A comes back online

Expected Result:

Confirm the money request is not paid, and User A sees an error message: The requested amount has changed.

Actual Result:

No error message after user B changes the amount, and user A goes back online from the paid expense

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

bug.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ZhenjaHorbach

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022043678322317186179
• Upwork Job ID: 2043678322317186179
• Last Price Increase: 2026-04-20

[MelvinBot]

Proposal

What is the root cause of that problem?

When User A taps "Pay" while offline, payMoneyRequest() captures the report total from the local Onyx cache (line 199) and queues the request via API.write() (line 775) without a conflictResolver. The optimistic data immediately marks the report as REIMBURSED (line 275).

While User A is offline, User B's changes to the expense amount never reach User A's Onyx store. When User A reconnects, the SequentialQueue flushes the queued payment with the stale amount. Even if the server rejects the payment, the client's failureData only shows a generic error (iou.error.other → "Unexpected error. Please try again later.") — there is no translation key or error handling for an "amount has changed" scenario anywhere in the App codebase.

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

Two things need to happen:

1. Add a specific error translation key for amount mismatch — e.g., iou.error.amountChanged in src/languages/en.ts (and other locale files) with a message like "The requested amount has changed. Please review and try again."

2. Handle the server's amount-mismatch rejection in failureData — the server likely returns a specific error code when the submitted amount param doesn't match the current report total. The client should map that server error to the new amountChanged translation key instead of the generic iou.error.other. This would require updating the failureData construction in getPayMoneyRequestParams() to check for and surface amount-specific errors from the server's onyxData response.

   Alternatively, if the server doesn't currently validate the amount parameter, server-side validation should be added to reject PayMoneyRequest when the submitted amount doesn't match the current report total — and the client should handle that rejection with the specific error message.

What alternative solutions did you explore? (Optional)

• Client-side pre-flight validation: Making a read API call before payment to compare local vs server amount. Rejected because this breaks offline-first architecture — the user should be able to initiate payment while offline.
• Using a conflictResolver on the API.write() call to update the queued request's amount before sending on reconnect. This would prevent sending stale data but wouldn't address the core issue that the amount changed without the payer's knowledge — the user should be informed, not silently corrected.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[trasnake87]

Proposal

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

When User A queues a "Pay" action offline and User B modifies the expense amount in the meantime, User A's payment silently succeeds (or fails generically) on reconnect instead of surfacing a clear "requested amount has changed" error.

What is the root cause of that problem?

The SettlementButton component fires the payment via its onPress handler at src/components/SettlementButton/index.tsx without snapshotting the iouReport.total it displayed to the user. Because the queued request carries no "expected amount" fingerprint, neither the client nor the re-hydrated Onyx state on reconnect can detect divergence. Additionally, the reconnect refresh path in src/libs/actions/App.ts → reconnectApp() runs in parallel with the SequentialQueue flush, so fresh iouReport.total from the server arrives too late to block the stale payment.

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

Capture the displayed amount at click time in SettlementButton and validate it against the current Onyx cache right before dispatching, blocking the send and showing an inline error on the report when they diverge:

// src/components/SettlementButton/index.tsx
const handlePayment = (type: PaymentMethodType) => {
    const expectedTotal = iouReport?.total;
    const latestReport = ReportConnection.getAllReports()?.[`${ONYXKEYS.COLLECTION.REPORT}${iouReport?.reportID}`];
    if (latestReport && latestReport.total !== expectedTotal) {
        Report.setLocalReportError(iouReport.reportID, {
            [DateUtils.getMicroseconds()]: translateLocal('iou.error.amountChanged'),
        });
        return;
    }
    onPress(type);
};

Pair with a new iou.error.amountChanged entry in the locale files and surface it via the existing ReportActionItemBasicMessage error row so the user sees "The requested amount has changed" immediately on reconnect — no backend contract change required.

[trasnake87]

Contributor details
Your Expensify account email: trasnake87@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~010f770315ab181656

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[skylarkerx]

Proposal

1. Problem description

While User A is offline, they optimistically Pay a workspace expense report. User B changes the expense amount (or adds another expense) before A reconnects. After A goes back online, the product expectation is that the payment does not complete as if nothing changed, and A sees an error such as “The requested amount has changed.” Instead, A does not get that feedback (the UI can remain in a “paid” / settled path without the expected error).

2. What is the root cause of that problem?

Stale payment payload vs. live report totals after sync. The pay flow snapshots the payable total and sends it on the write; that snapshot is fixed at the time the offline write is created and is replayed from the persisted queue when connectivity returns. If the report’s reimbursable total changed in the meantime, the client has no first-class check that the queued amount still matches the current IOU report before the API runs.

PayMoneyRequest.ts (L199–216, L447–461)

let total = (iouReport?.total ?? 0) - (iouReport?.nonReimbursableTotal ?? 0);
// ...
const optimisticIOUReportAction = buildOptimisticIOUReportAction({
    // ...
    isSettlingUp: true,
});
// ...
params: {
    iouReportID: iouReport?.reportID,
    // ...
    amount: Math.abs(total),

API/index.ts (L147–148)

// All calls to API.write() will be persisted to disk as JSON with the params, successData, and failureData

Offline “safe to settle” gating does not cover this race. hasUpdatedTotal mainly guards pending/optimistic report or transaction state (e.g. pendingFields?.total, pending transactions, held-expense edge cases)—not “queued pay amount ≠ current report total after another user edited.”

ReportUtils.ts (L10883–10899)

function hasUpdatedTotal(report: OnyxInputOrEntry<Report>, policy: OnyxInputOrEntry<Policy>): boolean {
    // ...
    return !(hasPendingTransaction && (hasTransactionWithDifferentCurrency || hasDifferentWorkspaceCurrency)) && !hasOptimisticHeldExpense && !report.pendingFields?.total;
}

PayPrimaryAction.tsx (L85–86, L181–182)

const canAllowSettlement = hasUpdatedTotal(moneyRequestReport, policy);
// ...
isDisabled={isOffline && !canAllowSettlement}

If the API responds with success, the client applies successData (optimistic payment completes “for real” in Onyx). If the API responds with failure, pay failures are wired to a generic IOU error on the pay action, not a dedicated “amount changed” string (that exact copy does not appear in en.ts today).

OnyxUpdates.ts (L41–48)

return onyxDataUpdatePromise.then(() => {
    if (response.jsonCode === 200 && request.successData) {
        return updateHandler(request.successData);
    }
    if (response.jsonCode !== 200 && request.failureData) {

PayMoneyRequest.ts (L340–347)

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

en.ts (iou.error.other, L1503)

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

So the gap is behavioral: either the backend accepts a pay when it should reject on amount mismatch, and/or the client never reconciles queued amount with post-sync report state and never surfaces the specific expected message (whether that string lives only on the API today or is intended as product copy).

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

• Backend / API (primary): Ensure PayMoneyRequest / PayMoneyRequestWithWallet rejects when the client-supplied amount does not match the current payable total for the IOU report (including after edits or added expenses), and returns a stable error code / message that product can rely on (aligned with “The requested amount has changed.” if that is the canonical copy).

• Client queue / persistence: Before sending a replayed pay write (or when merging server updates into Onyx for that report), compare the persisted amount to the live computed payable total for the same iouReportID. If they differ, drop or fail the queued pay locally and surface the same user-visible error (via a dedicated translation key if the string is meant to be client-owned).

• Failure UX: When the API returns the amount-mismatch error, map it to that string (or add iou.error.* copy) instead of only iou.error.other, and ensure the error attaches to the pay report action (or report-level RBR) so it is visible in the chat report view.

• Regression: Add an automated test (Jest and/or BrowserStack scenario) that mirrors the repro: offline pay → partner edit → reconnect → assert no false “paid” state and assert the expected error message.

4. An alternative considered

Disable paying while offline for workspace expense reports (or whenever another participant can still edit expenses), so the stale amount never enters the persisted queue. That avoids the race but reduces offline functionality and may conflict with current UX where offline pay is allowed when hasUpdatedTotal passes—so it is a product tradeoff, not a complete substitute for server-side validation + clear error handling.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-04-21 13:44:44 UTC.

Proposal

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

When User A taps Pay while offline and User B changes the expense amount before A reconnects, A's queued payment is replayed with a stale amount. Even when the BE rejects the replay, A sees the generic Unexpected error. Please try again later. instead of a specific "amount has changed" message, so A has no clear signal that the amount must be re-reviewed.

What is the root cause of that problem?

Authoritative amount validation belongs on the server — the BE is the only component that knows the current report total at the moment the replayed pay request is processed. The FE gap is purely in error surfacing: the failure path in OnyxUpdates.applyHTTPSOnyxUpdates applies request.failureData as-is, and failureData in getPayMoneyRequestParams() always maps to iou.error.other. There is no dedicated iou.error.amountChanged key, and no logic that inspects the BE's response to upgrade the generic error into a specific one. So even when the server rejects for the right reason, the user sees the wrong message.

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

Keep the FE change minimal and focused on error UX:

1. Add a dedicated translation key iou.error.amountChanged in src/languages/en.ts and the other locale files, with copy such as The requested amount has changed. Please review and try again.

2. Map the BE's amount-mismatch response to that key inside the failure branch of OnyxUpdates.applyHTTPSOnyxUpdates. Preferred contract: BE returns a stable jsonCode / error type for amount mismatch on PayMoneyRequest / PayMoneyRequestWithWallet, and the FE keys off that code. If no such code exists yet, the FE can detect the mismatch numerically by comparing the submitted amount against the fresh total in response.onyxData for the same iouReportID (evidence-based, not string-matching on error copy) as a stopgap until a stable BE contract is exposed.

3. Cover both commands — PAY_MONEY_REQUEST and PAY_MONEY_REQUEST_WITH_WALLET.

What alternative solutions did you explore? (Optional)

• Replay-time guard in SequentialQueue — comparing the queued amount against the latest local report total before dequeuing. Rejected after tracing the reconnect flow: the stale PayMoneyRequest sits ahead of RECONNECT_APP in the FIFO queue, so local Onyx total will still be stale at replay time unless Pusher happens to deliver the amount-edit event first. The guard passes stale-vs-stale in exactly the scenario it should catch, making it racy and unreliable. It is a best-effort optimization at most, not a correctness fix.

• Button-time preflight in SettlementButton — rejected because the race window extends past the click, through queue persistence, until replay on reconnect. A click-time check cannot catch edits that land after the click but before replay.

• Server-only fix with no FE change — insufficient on its own: even with correct BE rejection, the user still sees the generic iou.error.other until the FE maps the response to a specific key.