"Create a rule" prompt appears after editing the expense on self DM & submitting to workspace

[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 self DM.
3. Create an expense with merchant and category.
4. Open the expense.
5. Change the category.
6. Go back to self DM.
7. Click Submit to my friend.
8. Select workspace chat > Create expense.
9. Open the expense.

Expected Result:

"Create a rule" prompt will not appear after editing the expense on self DM and submitting it to workspace.

Actual Result:

"Create a rule" prompt appears after editing the expense on self DM and submitting it to workspace.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7256544_1789083173768.6.mp4

View all open jobs on GitHub

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

[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/f0c12f04028e49abfc5b0c5a8950dca5a5db797ff959e5211a0be33992a76b7e

[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 feature issue this PR implements)

Recommendation: ROLL FORWARD

The whole "Create a rule" callout is new in this release (matching "N/A in prod — new feature"), so #99164 is unambiguously the cause, but it is a ~50-file feature PR and the defect is a single missing guard in one helper — a targeted fix is far cheaper and lower risk than a revert plus full re-QA of the feature.

Assigned: @Krishna2323 (PR author), @JS00001 and @situchan (approving reviewers) — already assigned by Melvin, no change needed.
Labels: No changes. DeployBlockerCash stays (App PR caused it, fix is in App); DeployBlocker was not present, so nothing to remove.

📋 Detailed Analysis

Evidence

• The callout, its Onyx record and every file that drives it (MerchantRuleSuggestionBanner.tsx, useMerchantRuleSuggestion.ts, MerchantRuleSuggestion.ts, MerchantRuleSuggestionUtils.ts) were added by Surface "Create a rule" prompt on expense edits to drive merchant rule adoption in-situ #99164 (merged 2026-09-10, merge commit 43f1e25). None of them exist on production, which is exactly why the reporter marked production as N/A.
• Surface "Create a rule" prompt on expense edits to drive merchant rule adoption in-situ #99164 is on the 9.4.76-0 checklist (Deploy Checklist: New Expensify 2026-09-10 #100893); no other PR on that checklist touches the merchant-rule-suggestion code, and the production...staging compare shows the MerchantRuleSuggestion* files as the only changed files in this area.
• No backend involvement: the prompt's visibility is decided entirely client-side from an in-memory Onyx record.

Verification

Affected files, all introduced or modified by #99164 (confirmed against gh pr view 99164 --json files):

• src/libs/actions/MerchantRuleSuggestion.ts#L22-L48 — records the suggestion
• src/libs/actions/IOU/UpdateMoneyRequest.ts#L1343 — the category-edit call site from the repro
• src/hooks/useMerchantRuleSuggestion.ts#L52-L63 — decides whether the callout renders
• src/pages/inbox/report/ReportActionsList.tsx#L456-L461 — renders the banner with the currently open report's policyID

Root Cause

Two independent gaps in #99164 line up to produce the bug. Either one, closed, prevents it.

1. The edit is recorded even though the expense is not on a workspace.

trackMerchantRuleSuggestion only records the offer for a Control workspace with Rules on:

if (!transactionID || !reportID || !isControlPolicy(policy) || !arePolicyRulesEnabled(policy, policyCategories)) {
    return;
}

(MerchantRuleSuggestion.ts#L33)

The policy it is handed is not the policy that owns the expense. For a self-DM (unreported) expense, usePolicyForTransaction.ts#L56-L60 deliberately falls back to policyForMovingExpenses — the user's active/only workspace, i.e. the workspace the expense would move to — and that is what DynamicIOURequestStepCategory.tsx#L86-L94 passes to updateMoneyRequestCategory. That is how a self-DM expense can show workspace categories at all.

So at step 5 the guard sees the tester's Control workspace, passes, and writes a suggestion for a self-DM expense. The callout does not show in the self DM only because the self DM report has no policyID — the record is silently armed, not blocked.

2. The armed record follows the transaction into the workspace.

At steps 7–8 the tracked expense is converted/moved into the workspace chat, keeping the same transactionID. When the new expense is opened, the banner is mounted with the new report's policyID (the Control workspace), and the hosting check matches on transaction identity rather than the recorded report:

const isOneExpenseReportForSuggestion = reportTransactions.length === 1 && reportTransactions.at(0)?.transactionID === storedSuggestion?.transactionID;
const isHostingReport = !!reportID && (reportID === storedSuggestion?.reportID || isOneExpenseReportForSuggestion);

(useMerchantRuleSuggestion.ts#L53-L54)

The brand-new one-expense report holds exactly that transaction, so isHostingReport is true; canCreateMerchantRule (L62) is now evaluated against the Control policy and also passes. The offer from the self-DM edit surfaces on the workspace expense. isRetired does not save us either: the self DM never rendered the callout, so markMerchantRuleSuggestionSeen never ran and useRetireMerchantRuleSuggestionOnLeave has nothing to retire on the way out.

Suggested fix (roll forward)

Preferred, at the source — only record an offer when the expense actually lives on that workspace. Pass the expense's own report policy into trackMerchantRuleSuggestion and bail when it doesn't match policy.id (for a self-DM/unreported expense there is no report policy, so it bails). isSelfDM / isExpenseUnreported are already imported in UpdateMoneyRequest.ts, so an isExpenseUnreported(transaction) || isSelfDM(parentReport) early return at the six trackMerchantRuleSuggestion call sites is the smallest possible change.

Worth adding as defence in depth: store the policyID on the suggestion record and require it to equal the rendering report's policyID in useMerchantRuleSuggestion. That additionally stops an offer following an expense moved between two Control workspaces, which the current isOneExpenseReportForSuggestion heuristic also allows.