[Due for payment 2026-08-21] [$250] [Exploratory] Rules - Updating Require Receipts field reverts to previous value after saving

[applause-bot]

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.4.28-0
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://test-management.browserstack.com/projects/2219752/test-runs/63494199/folder/13176707/41236885/1545045542?p=2
Email or phone of affected tester (no customers): applausetester+bm88yu@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Web, android
App Component: Workspace Settings

Action Performed:

Preconditions:
Use expensifail account
Create Workspace and enable rules

1. Go to staging.new.expensify.com
2. Navigate to Workspace Settings > Rules.
3. Click on Require Receipts.
4. Update the Require itemized receipt and Require receipt fields to 100.
5. Save the rule.
6. Open Require Receipts again.

Expected Result:

Require receipt field should save and display the updated value.

Actual Result:

Require receipt field is not updated and reverts to the previous value.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7201052_1783362707494.bandicam_2026-07-06_21-26-32-714.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7201052

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022078173294317512469
• Upwork Job ID: 2078173294317512469
• Last Price Increase: 2026-07-24

Issue Owner

Current Issue Owner: @mallenexpensify

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/3dfe0a581d858be53c2f40e92a1795b5b1744d242dfd472ab3ffd3e37b71aeeb

[MelvinBot]

Updated 2026-07-17: Corrected. My earlier conclusion that this was a backend-only issue was wrong — it is reproducible and fixable entirely in App. wildan-m's proposal below correctly identifies the root cause and fix.

Issue Analysis

Root Cause: This is an App-side request-ordering bug, not a race. The two amounts are governed by the invariant Require receipt ≤ Require itemized receipt, which the backend validates per request. The combined page always dispatches the receipt update first, then the itemized update (RulesRequireReceiptsPage.tsx:139-143). When both are raised together (e.g. old itemized 50 → both to 100), the receipt request (100) is validated against the itemized value still stored on the server (50), so 100 > 50 fails. Its failureData then rolls the receipt amount back to the previous value (Policy.ts failureData). The itemized request, sent second, succeeds — producing the exact symptom: itemized saved, receipt reverted.

Recommended Fix: In handleSubmit, dispatch the two updates in the order that keeps the server state valid at every step, rather than always receipt-first:

• Raising (this bug): send setPolicyMaxExpenseAmountNoItemizedReceipt before setPolicyMaxExpenseAmountNoReceipt.
• Lowering: keep the current receipt-first order.

Compute the safe order from the old vs. new values (treating disabled/0 as unbounded). Both requests then pass the server check. This is fully contained in App and touches only the two calls at RulesRequireReceiptsPage.tsx:139-143. wildan-m's proposal already lays this out correctly.

Investigation details & evidence

The invariant is real and enforced client-side on the individual (non-revamp) pages — validated against the stored policy value, which is what makes the ordering matter:

• Receipt page rejects receipt > stored itemized (RulesReceiptRequiredAmountPage.tsx:55-70).
• Itemized page rejects itemized < stored receipt (RulesItemizedReceiptRequiredAmountPage.tsx:58-68).

Why the combined page slips through: its own validate() compares the two new values against each other (100 ≤ 100 ✓), so the client allows the submit. But each of the two resulting API requests is validated server-side against the old stored counterpart, and the first one (receipt) fails against the stale, lower itemized value.

The rollback that produces the revert: setPolicyMaxExpenseAmountNoReceipt sets failureData.maxExpenseAmountNoReceipt = currentMaxExpenseAmountNoReceipt (Policy.ts:6183-6194), restoring the previous value when the server rejects the request.

Why only now: before the Rules Revamp (R2, #92741) each amount lived on its own page and was never saved simultaneously, so the ordering conflict never arose. The combined page introduced it.

Correction to my earlier comment: I originally described this as a backend "later-write-wins" race requiring an internal fix. That was wrong — the direction of the revert is explained deterministically by request ordering + server-side invariant validation + failureData rollback, all observable in App code, and it is fixable in App.

Confidence: High.

Possibly related: #92741 (Rules Revamp Release 2 — introduced the combined page).

---

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

[melvin-bot]

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

[wildan-m]

Proposal

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

On the Workspace Settings > Rules > Require Receipts page, when the "Require receipt" and "Require itemized receipt" amounts are both updated (for example both set to 100) and the rule is saved, the "Require receipt" value is not persisted and reverts to its previous value when the page is reopened.

What is the root cause of that problem?

The "Require receipts" page saves the two amounts as two separate, independent API requests, and it always sends them in the same fixed order — the "Require receipt" amount first, then the "Require itemized receipt" amount:

App/src/pages/workspace/rules/RulesRequireReceiptsPage.tsx

Lines 126 to 158 in ea76f80

	const handleSubmit = useCallback(
	(values: FormOnyxValues<typeof ONYXKEYS.FORMS.RULES_REQUIRE_RECEIPTS_FORM>) => {
	const receiptChanged = receiptEnabled !== initialReceiptEnabled || (receiptEnabled && values.maxExpenseAmountNoReceipt !== initialReceiptAmount);
	const itemizedChanged = itemizedEnabled !== initialItemizedEnabled || (itemizedEnabled && values.maxExpenseAmountNoItemizedReceipt !== initialItemizedAmount);
	if (!receiptChanged && !itemizedChanged) {
	Navigation.goBack();
	return;
	}
	const receiptValue = receiptEnabled ? values.maxExpenseAmountNoReceipt : '';
	const itemizedValue = itemizedEnabled ? values.maxExpenseAmountNoItemizedReceipt : '';
	if (receiptChanged) {
	setPolicyMaxExpenseAmountNoReceipt(policyID, receiptValue, policy?.maxExpenseAmountNoReceipt);
	}
	if (itemizedChanged) {
	setPolicyMaxExpenseAmountNoItemizedReceipt(policyID, itemizedValue, policy?.maxExpenseAmountNoItemizedReceipt);
	}
	Navigation.setNavigationActionToMicrotaskQueue(Navigation.goBack);
	},
	[
	receiptEnabled,
	initialReceiptEnabled,
	initialReceiptAmount,
	itemizedEnabled,
	initialItemizedEnabled,
	initialItemizedAmount,
	policyID,
	policy?.maxExpenseAmountNoReceipt,
	policy?.maxExpenseAmountNoItemizedReceipt,
	],
	);

The two values are governed by an invariant: the "Require receipt" amount must be less than or equal to the "Require itemized receipt" amount. The frontend enforces this same invariant on the individual (non-revamp) pages — the receipt page rejects a value greater than the current itemized amount, and the itemized page rejects a value lower than the current receipt amount:

App/src/pages/workspace/rules/RulesReceiptRequiredAmountPage.tsx

Lines 59 to 68 in ea76f80

	// Check if receipt required amount is greater than itemized receipt required amount
	if (
	maxExpenseAmountNoItemizedReceipt !== CONST.DISABLED_MAX_EXPENSE_VALUE &&
	maxExpenseAmountNoItemizedReceipt !== 0 &&
	maxExpenseAmountNoReceiptInCents > maxExpenseAmountNoItemizedReceipt
	) {
	errors.maxExpenseAmountNoReceipt = translate('workspace.rules.individualExpenseRules.receiptRequiredAmountError', {
	amount: convertToFrontendAmountAsString(maxExpenseAmountNoItemizedReceipt, getCurrencyDecimals(policy?.outputCurrency)),
	});
	}

App/src/pages/workspace/rules/RulesItemizedReceiptRequiredAmountPage.tsx

Lines 61 to 66 in ea76f80

	// Check if itemized receipt amount is lower than regular receipt amount
	if (maxExpenseAmountNoReceipt !== CONST.DISABLED_MAX_EXPENSE_VALUE && maxExpenseAmountNoItemizedReceiptInCents < maxExpenseAmountNoReceipt) {
	errors.maxExpenseAmountNoItemizedReceipt = translate('workspace.rules.individualExpenseRules.itemizedReceiptRequiredAmountError', {
	amount: convertToFrontendAmountAsString(maxExpenseAmountNoReceipt, getCurrencyDecimals(policy?.outputCurrency)),
	});
	}

The backend enforces the same rule. Because the two updates are sent as separate sequential requests, the "Require receipt" request is validated against the value of the itemized amount that is still stored on the server at that moment — the old, lower value. When both amounts are raised together, sending the receipt update first means it is checked while the itemized amount on the server is still the previous (lower) number, so the receipt update is rejected. Its optimistic change is then rolled back by the request's failureData, which restores the previous "Require receipt" value:

App/src/libs/actions/Policy/Policy.ts

Lines 6072 to 6082 in ea76f80

	failureData: [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.POLICY}${policyID}`,
	value: {
	maxExpenseAmountNoReceipt: currentMaxExpenseAmountNoReceipt,
	pendingFields: {maxExpenseAmountNoReceipt: null},
	errorFields: {maxExpenseAmountNoReceipt: ErrorUtils.getMicroSecondOnyxErrorWithTranslationKey('common.genericErrorMessage')},
	},
	},
	],

The itemized update, sent second, succeeds. The net result is exactly the reported symptom: the itemized amount is saved but the "Require receipt" amount silently reverts.

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

In the handleSubmit callback of RulesRequireReceiptsPage, choose the order in which the two updates are dispatched so that no intermediate server state ever violates the "receipt must be less than or equal to itemized" invariant, instead of always sending the receipt update first.

There are only two possible orderings, and at least one is always safe:

• Sending the itemized update first is safe when the current (old) receipt amount is less than or equal to the new itemized amount.
• Sending the receipt update first is safe when the new receipt amount is less than or equal to the current (old) itemized amount.

So the fix is: when raising the amounts (the case in this bug), dispatch the "Require itemized receipt" update before the "Require receipt" update; when lowering, keep the existing receipt-first order. Concretely, compute the safe order from the old and new values (using the disabled/zero states as effectively unbounded where appropriate) and call setPolicyMaxExpenseAmountNoItemizedReceipt and setPolicyMaxExpenseAmountNoReceipt in that order. Both requests then pass the server-side check and both values persist.

This keeps the two existing API commands untouched and only reorders the two calls that are already made here:

App/src/pages/workspace/rules/RulesRequireReceiptsPage.tsx

Lines 139 to 144 in ea76f80

	if (receiptChanged) {
	setPolicyMaxExpenseAmountNoReceipt(policyID, receiptValue, policy?.maxExpenseAmountNoReceipt);
	}
	if (itemizedChanged) {
	setPolicyMaxExpenseAmountNoItemizedReceipt(policyID, itemizedValue, policy?.maxExpenseAmountNoItemizedReceipt);
	}

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/95423-fix-require-receipts-save-order?expand=1

What alternative solutions did you explore? (Optional)

Add a single combined backend command that updates both amounts atomically in one request, so no transient intermediate state exists. This is more robust but requires a new API command and backend work, whereas the ordering fix is fully contained in the frontend and resolves the reported behavior.

[melvin-bot]

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