Rules - Deleted personal rules are still applied to newly created expenses

[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.22-1
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #82438
Email or phone of affected tester (no customers): applausetester+usggsga@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: iPhone 13 / iOS 18.7.1, Samsung Galaxy A52 / Android 14, Windows 11 / Chrome
App Component: Workspace Settings

Action Performed:

Preconditions:

1. Add a custom category "Software" in a workspace
2. enable rule in more feature of the workspace

Steps:

1. Create workspace rule for "Amazon" → Category: "Office Supplies"
2. Create personal rule for "Amazon" → Category: "Software"
3. Create workspace rule for "Amazon" → Category: "Travel" (newer, should lose)
4. Create an expense to the workspace with merchant: "Amazon"
5. Verify personal rule wins → Category: "Software"
6. Delete personal rule
7. Create another expense to the workspace with merchant: "Amazon"

Expected Result:

after step 7, oldest workspace rule wins → Category: "Office Supplies"

Actual Result:

after step 7, the deleted personal rules are still applied to newly created expenses → Category: "Software"

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

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[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.

[OSBotify]

🔍 Investigation Summary

Classification: Backend bug / Pre-existing rules bug
Causing PR: #82438 - "Enable merchant rules v2" by @luacmartins (High confidence)
Related Issues: None found

Recommendation: NEEDS INVESTIGATION

PR #82438 only removed the isProduction feature flag check that was hiding the merchant rules feature. The PR did not modify any rules evaluation or deletion logic. The bug - where deleted personal expense rules continue to be applied to newly created expenses - suggests the issue lies in either:

1. Backend not properly processing the SetNameValuePair call that deletes personal rules (NVP_EXPENSE_RULES)
2. Backend evaluating rules from cached/stale data when applying them to new expenses
3. Pre-existing bug in the rules implementation that was hidden while the feature was behind a flag

This requires investigation by the backend team and/or @luacmartins to determine where the rule evaluation/deletion is failing.

Labels: Keep DeployBlockerCash - This is blocking the App deploy as it involves expense rule functionality in the frontend, even though the root cause may be backend-related.

📋 Detailed Analysis

Evidence

• PR Enable merchant rules v2 #82438 merged on 2026-02-18 and only removed 6 lines of code - the isProduction check
• The merchant rules feature was previously hidden behind this production flag
• Issue reproduction steps involve creating and deleting personal expense rules, then creating a new expense
• The deleted rule incorrectly applies to the new expense

Code Analysis

From src/libs/actions/User.ts, the deleteExpenseRules function:

• Sets pendingAction: DELETE on the rule optimistically
• Removes the rule from successData
• Calls SetNameValuePair API with the filtered rules list
• On failure, restores the rule with an error

The deletion logic appears correct in the frontend. The issue must be either:

• Backend not properly persisting the deletion
• Backend evaluating rules from a different data source/cache
• Race condition where the new expense is created before deletion completes

Root Cause

The root cause requires backend investigation to determine:

1. Whether SetNameValuePair for NVP_EXPENSE_RULES is properly deleting rules on the backend
2. Where/how the backend evaluates and applies rules to newly created expenses
3. Whether there is caching or stale data causing old rules to be applied

Files Involved

• /home/runner/_work/App/App/src/pages/workspace/rules/MerchantRulesSection.tsx (PR Enable merchant rules v2 #82438 changes)
• /home/runner/_work/App/App/src/libs/actions/User.ts (deleteExpenseRules function)
• /home/runner/_work/App/App/src/pages/settings/Rules/ExpenseRulesPage.tsx (personal rules UI)
• Backend API: SetNameValuePair for NVP_EXPENSE_RULES
• Backend: Rule evaluation logic (location unknown, needs investigation)

[OSBotify]

🔍 Update: Label Decision

After further analysis, I am NOT removing any deploy blocker labels at this time.

Reason: The root cause is unclear and requires investigation to determine whether the fix needs to happen in App (frontend) or backend.

Keep Both Labels:

• DeployBlockerCash - Keep (App deploy blocked)
• DeployBlocker - Keep if present (Backend deploy may also be blocked)

The bug involves the interaction between personal expense rules and merchant rules after enabling the merchant rules feature. Until we can confirm:

1. Whether the deletion is failing on the frontend or backend
2. Whether the rule evaluation is happening incorrectly in App or backend
3. Whether there is a conflict between the two rules systems

We should maintain the conservative approach and keep all deploy blocker labels in place. The PR author @luacmartins and backend team need to investigate before we can confidently determine the fix location and adjust labels accordingly.