Expense - "Contains" match type not working for two-word merchant

[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): dreamnitethedragon@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redminote 10S Android 13
App Component: Money Requests

Action Performed:

1. Launch app
2. Go to workspace settings
3. Enable rules
4. Create a merchant rule
5. Merchant - polo shirt ( contains)
   Update category to equipment
6. Tap save
7. Create expense with merchant polo
8. Category is not updated and it displays missing category

Expected Result:

With match type set to "contains", the rule should apply if the merchant name contains any matching part of the defined value.
The category should update automatically as configured.
"Missing category" should not be shown.

Actual Result:

When a merchant rule is created with two words (e.g., "polo shirt") and match type set to "contains", the rule is not applied if the expense merchant name contains only one of the words (e.g., "polo").
The category is not updated.
"Missing category" is displayed.

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 @sonialiap (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
Causing PR: #82438 - "Enable merchant rules v2" by @luacmartins (High confidence that this PR exposed the issue)
Related Issues: None

Recommendation: REMOVE DeployBlockerCash LABEL

The merchant rule matching logic is implemented on the backend, not in the App. PR #82438 only removed a production flag check that was hiding the merchant rules feature from users - it did not implement or modify any matching logic.

Evidence that this is a backend issue:

1. PR Enable merchant rules v2 #82438 only removed the if (isProduction) { return null; } check in MerchantRulesSection.tsx
2. The App sends rule configuration to the backend via SET_POLICY_CODING_RULE API command (see src/libs/actions/Policy/Rules.ts)
3. The actual matching of merchant names against rules happens on the backend when expenses are created/modified
4. No App code performs the "contains" matching - this logic lives in the backend

Why the bug appeared:

• Merchant rules were previously hidden in production via the removed flag
• Enabling the feature exposed a pre-existing backend bug in the "contains" operator logic
• The backend is not correctly matching "polo" against a rule with "polo shirt" (contains)

Labels: Removing DeployBlockerCash because this requires a backend fix, not an App PR revert. Keeping DeployBlocker to block the backend/Web deploy until the backend matching logic is fixed.

📋 Detailed Analysis

Evidence

The issue states:

• Rule created: merchant "polo shirt" with match type "contains"
• Expense created: merchant "polo"
• Expected: Rule should match (user expects word-based or partial matching)
• Actual: Rule does not match, shows "Missing category"

PR #82438 changes:

// Only change: Removed these lines from MerchantRulesSection.tsx
-    const {isProduction} = useEnvironment();
-    if (isProduction) {
-        return null;
-    }

Verification

Confirmed that PR #82438 modifies only one file: src/pages/workspace/rules/MerchantRulesSection.tsx

The rule creation and matching flow:

1. User creates rule in UI (MerchantRulesSection)
2. App calls setPolicyCodingRule() which sends data to backend API
3. Backend stores the rule with operator "contains"
4. When expense is created, backend evaluates rules and applies matches
5. Backend "contains" logic is not working as expected

Root Cause

The backend merchant rule matching logic does not handle the "contains" operator correctly for multi-word patterns. This is a backend implementation issue, not an App bug.