[Due for payment 2026-07-06] [Due for payment 2026-07-03] Rules - App crashes after opening Expense defaults

[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.20-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #94478
Email or phone of affected tester (no customers): applausetester+ssndjois2jd1@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Log in with Expensifail account.
• Enable Rules.

1. Go to staging.new.expensify.com
2. Go to workspace settings > Rules.
3. Go to Expense defaults.

Expected Result:

App will not crash.

Actual Result:

App crashes.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7191439_1782425638399!staging.new.expensify.com-1782424230605.txt

Bug7191439_1782425638396.1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7191439

Issue Owner

Current Issue Owner: @Krishna2323

[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/6a5586828d47942a3e21559e59c310b5156e683aceb37cfbb1f2e68c95e09769

https://platform.applause.com/services/links/v1/external/ce4348b5b15fbe09eecdbcc9090b6637228627dd43c38c99d732019f295b7e8e

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #94478

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

⏱️ Ran out of time before I could finish. This usually means the task was too complex or I got stuck exploring. Please try again with a more specific request or post in #melvinbot-ai.

Run details

[situchan]

Problem

Opening Workspace settings → Rules → Expense defaults crashes with React error #185 ("Maximum update depth exceeded"). Only the Expense defaults tab crashes — Card restrictions is fine.

Root cause: PR #94478 changed the table's selectedKeys prop from the stable selectedExpenseDefaultKeys state to a derived filteredSelectedExpenseDefaultKeys:

const validExpenseDefaultKeys = new Set(
  expenseDefaultsTableData
    .filter((rule) => !rule.disabled)
    .map((rule) => rule.keyForList),
);
const filteredSelectedExpenseDefaultKeys = canWriteRules
  ? selectedExpenseDefaultKeys.filter((key) => validExpenseDefaultKeys.has(key))
  : [];

This page relies on React Compiler for memoization (no manual useMemo). But the compiler does not memoize the expenseDefaultsTableData chain, so filteredSelectedExpenseDefaultKeys is a brand-new array on every render. That unstable selectedKeys prop makes the table's JSX (and its derived processedData/context) re-create every render, driving a downstream layout-effect setState into an infinite loop.

Why the compiler bailed (proven by compiling variants of the real file): the .sort() at the tail of expenseDefaultsTableData. React Compiler refuses to memoize values produced via the array sort methods.

Variant	Change	expenseDefaultsTableData memoized?
Original	as merged	❌ No
spendRulesTableData	reference — has no .sort()	✅ Yes
A	remove .sort()	✅ Yes
B	.sort() w/ comparator not reading outer state	❌ No
E	.sort() + items don't alias rule/codingRules	❌ No
F	.toSorted() (non-mutating)	❌ No
G	.slice().sort() (sort a fresh copy)	❌ No

It is not the comparator's captures (B), not item aliasing (E), and not in-place mutation (F, G all bail). .map()/.filter() memoize fine; the sort methods are modeled as effectful and the reactive scope is pruned → recomputed every render. spendRulesTableData has no .sort(), so its chain memoizes — hence only Expense defaults loops.

Solution 1 (no useMemo)

Remove the redundant page-level .sort() from expenseDefaultsTableData:

-              })
-              .sort((a, b) => {
-                  const ruleA = codingRules[a.ruleID];
-                  const ruleB = codingRules[b.ruleID];
-                  if (ruleA?.created && ruleB?.created) {
-                      return ruleA.created < ruleB.created ? 1 : -1;
-                  }
-                  return 0;
               });

With the sort gone, React Compiler auto-memoizes the whole chain (expenseDefaultsTableData → validExpenseDefaultKeys → filteredSelectedExpenseDefaultKeys), so selectedKeys becomes referentially stable and the loop stops.

Behavior-preserving: WorkspaceExpenseDefaultsTable always re-sorts its data (activeSorting defaults to {columnKey: 'condition', order: 'asc'}), so the page-level created sort was already overridden — removing it has no visible effect. (Only nuance: ties on identical merchant text fall back to object-key order instead of created order — cosmetic.)

Solution 2 (with useMemo)

Wrap the derived selections in useMemo so they are referentially stable. React Compiler honors the manual memoization boundaries and even re-memoizes the upstream expenseDefaultsTableData chain (pulling fieldLabels inside a block keyed on codingRules/isOffline/policyID/translate).

Manuallt memoize the derived selection values:

-    const validExpenseDefaultKeys = new Set(expenseDefaultsTableData.filter((rule) => !rule.disabled).map((rule) => rule.keyForList));
-    const validSpendRuleKeys = new Set(spendRulesTableData.filter((rule) => !rule.disabled).map((rule) => rule.keyForList));
-    const filteredSelectedExpenseDefaultKeys = canWriteRules ? selectedExpenseDefaultKeys.filter((key) => validExpenseDefaultKeys.has(key)) : [];
-    const filteredSelectedSpendRuleKeys = canWriteRules ? selectedSpendRuleKeys.filter((key) => validSpendRuleKeys.has(key)) : [];
+    // These derived selections must be referentially stable: they are passed as the `selectedKeys` prop to the rules tables.
+    // React Compiler does not memoize the `expenseDefaultsTableData` chain, so without an explicit useMemo a brand-new array
+    // is produced on every render, which churns the table's derived data identity and triggers an infinite update loop
+    // ("Maximum update depth exceeded"). See https://github.com/Expensify/App/issues/94641.
+    const validExpenseDefaultKeys = useMemo(() => new Set(expenseDefaultsTableData.filter((rule) => !rule.disabled).map((rule) => rule.keyForList)), [expenseDefaultsTableData]);
+    const validSpendRuleKeys = useMemo(() => new Set(spendRulesTableData.filter((rule) => !rule.disabled).map((rule) => rule.keyForList)), [spendRulesTableData]);
+    const filteredSelectedExpenseDefaultKeys = useMemo(
+        () => (canWriteRules ? selectedExpenseDefaultKeys.filter((key) => validExpenseDefaultKeys.has(key)) : []),
+        [canWriteRules, selectedExpenseDefaultKeys, validExpenseDefaultKeys],
+    );
+    const filteredSelectedSpendRuleKeys = useMemo(
+        () => (canWriteRules ? selectedSpendRuleKeys.filter((key) => validSpendRuleKeys.has(key)) : []),
+        [canWriteRules, selectedSpendRuleKeys, validSpendRuleKeys],
+    );

Why it works: the useMemo makes filteredSelectedExpenseDefaultKeys / filteredSelectedSpendRuleKeys stable across renders, so the selectedKeys prop no longer changes identity every render and the infinite render loop stops. Verified via compiled output: expenseDefaultsTableData (t19, guarded by codingRules/isOffline/policyID/translate), validExpenseDefaultKeys (t23), and filteredSelectedExpenseDefaultKeys (t25) are all memoized.

Validation: react-compiler-compliance-check COMPILED; prettier clean; no new type errors; only the pre-existing grandfathered no-async-await lint error remains.

Trade-off vs. removing the .sort(): this fix is more locally explicit about intent, but adds manual memoization to a codebase that otherwise relies on React Compiler. The alternative (delete the redundant page-level .sort(), which the table overrides anyway) is smaller and stays idiomatic, but more subtle. Both fully fix the crash.

[Krishna2323]

checking...