Expense - "Create a rule" prompt is shown after inline editing category and opening expense

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.76-0
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: #99164
Email or phone of affected tester (no customers): applausetester+sddd1jsods32@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Log in with Expensifail account.
• Create a Control workspace.
• Enable Rules.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create two expenses with category.
4. Open the report.
5. Inline edit category of any expense.
6. Open the edited expense.

Expected Result:

"Create a rule" prompt will not appear after inline editing category and opening the expense.

Actual Result:

"Create a rule" prompt is shown after inline editing category and opening the expense.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7256562_1789085613317.8.mp4

View all open jobs on GitHub

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

[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/8d8c6ed8597e23a435562684ab9eae07c909b1d369a7dd26060d7c1dd1ffd28a

[melvin-bot]

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

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

[melvin-bot]

@JS00001 @situchan you have been assigned to this deploy blocker because you reviewed the offending PR: #99164

[melvin-bot]

@Krishna2323 you have been assigned to this deploy blocker because you authored the offending PR: #99164

[melvin-bot]

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

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #99164 - "Surface "Create a rule" prompt on expense edits to drive merchant rule adoption in-situ" by @Krishna2323 (High confidence)
Related Issues: #96354 (the issue #99164 implemented), deploy checklist #100893

Recommendation: ROLL FORWARD

The offer is recorded on every updateMoneyRequest* call regardless of the surface the edit was made on, so an inline edit in a multi-expense report queues a prompt that nothing can display at the time and nothing expires — it then fires the next time that expense is opened. The fix is a narrow change to when the offer is recorded/retired, and is much smaller and safer than reverting a 50-file PR that also refactored the existing Merchant Rules pages and added new routes/screens; if a fix is not up within the deploy window, revert #99164 as the fallback.

Assigned: @Krishna2323 (PR author), @JS00001 and @situchan (approving reviewers) from the highest-confidence causing PR only — already assigned by Melvin, no change needed.
Labels: No changes. DeployBlockerCash is kept (App-side fix). DeployBlocker was not present, so nothing was removed.

📋 Detailed Analysis

Evidence

• The "Create a rule" callout does not exist before #99164; that PR added MerchantRuleSuggestionBanner, the useMerchantRuleSuggestion hook, the MerchantRuleSuggestion actions and the RAM-only Onyx key wholesale. It merged 2026-09-10 and is item 28 on deploy checklist Deploy Checklist: New Expensify 2026-09-10 #100893, matching the 9.4.76-0 staging build and the "N/A - new feature, doesn't exist in prod" note in the report.
• The reported symptom (prompt appears on the expense detail view after an inline category edit made in the report list) is reproducible purely from the merged code path, see Root Cause below.
• Staging only; production is unaffected because the feature is new (and additionally gated behind the rulesRevamp beta + Control workspace + Rules enabled + Rules write access, which is why the repro requires exactly those preconditions).

Verification

Files that own the reported behaviour, all added or modified by #99164:

• src/libs/actions/MerchantRuleSuggestion.ts (new)
• src/hooks/useMerchantRuleSuggestion.ts (new)
• src/hooks/useRetireMerchantRuleSuggestionOnLeave.ts (new)
• src/components/MerchantRuleSuggestionBanner.tsx (new)
• src/libs/actions/IOU/UpdateMoneyRequest.ts#L1343 (modified — the category tracking call)

gh pr view 99164 --json files lists every one of these paths, and no other merged PR touches them (git log on those files shows only the #99164 introduction).

Root Cause

1. Every updateMoneyRequest* action records the offer unconditionally. For category that is UpdateMoneyRequest.ts#L1343, which passes transactionThreadReport?.reportID into trackMerchantRuleSuggestion. The action has no idea which screen the edit came from.
2. The inline-edit path goes through the same action: editTransactionCategoryInline builds its params via getIouParamsForTransaction, which creates the transaction thread report if one does not exist yet. So an inline edit made from the report list records an offer against the transaction thread reportID.
3. At edit time nothing can render it. useMerchantRuleSuggestion only shows the callout when the viewed report is the recorded report or is a report holding exactly one expense. The report in the repro holds two expenses and is not the thread, so the banner correctly stays hidden — and is therefore never marked seen via markMerchantRuleSuggestionSeen.
4. Nothing expires an offer that was never seen. useRetireMerchantRuleSuggestionOnLeave only retires when seenInReportID matched this report, so the "navigating away consumes the offer" safeguard never engages. The record stays live for the rest of the session.
5. Step 6 opens the transaction thread, whose reportID is exactly the recorded one, so isHostingReport is true and the banner fires — detached from the action that triggered it. It would equally fire minutes later, on any later visit to that expense.

Note the single-expense case works as designed (a one-expense expense report renders the detail view, so the callout appears in situ); the defect is specific to editing inline where the callout cannot be shown.

Suggested fix direction: only record the offer when the edit was made on a surface that can show the expense detail (i.e. have the inline-edit entry points in TransactionInlineEdit.ts opt out when the host report lists more than one expense), or retire an offer that has not been marked seen once the user leaves the report the edit was made in. Either keeps the in-situ behaviour the feature is for while preventing the queued, delayed prompt.