[Due for payment 2026-03-30] [$250] Expense - Category blank after resolving duplicate instead of showing disabled category

[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?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #79871
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. Open workspace chat
3. Create 2 expense with merchant (star) , amount (₹4), category ( advertising , benefits)
4. Disable both categories
5. Open expense report
6. Tap review duplicates - keep this one
7. Tap confirm

Expected Result:

After resolving duplicate: category field must show disabled category (Advertising)
Error message must consistently show “category no longer valid”
It should never be blank, and the error should not change to “missing category”

Actual Result:

After resolving duplicate: category field is blank
Error message briefly shows “category no longer valid” then changes to “missing category”

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

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022028951627042054896
• Upwork Job ID: 2028951627042054896
• Last Price Increase: 2026-03-17

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

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After resolving duplicate expenses where both have disabled categories (e.g., Advertising and Benefits), the category field becomes blank instead of showing the disabled category name. The error message briefly flashes "Category no longer valid" then changes to "Missing category."

What is the root cause of that problem?

The root cause is a gap in compareDuplicateTransactionFields at src/libs/TransactionUtils/index.ts:2466-2476. When determining which fields differ between duplicate transactions, categories are filtered to only include enabled categories:

const availableCategories = Object.values(policyCategories ?? {})
    .filter((category) => differentValues.includes(category.name) && category.enabled && ...)
    .map((e) => e.name);

When both duplicates have different disabled categories, availableCategories is empty. The code then falls through both conditional branches — the first requires availableCategories.length > 1, the second requires areAllFieldsEqualForKey (which is false since categories differ). So category is added to neither keep nor change.

Because setReviewDuplicatesKey uses Onyx.set() (full replacement, introduced in PR #79871) at src/libs/TransactionPreviewUtils.ts:89-97, the REVIEW_DUPLICATES Onyx key has no category field at all. When the user confirms, buildMergeDuplicatesParams at line 2545 reads reviewDuplicates?.category ?? '' which resolves to '' (empty string), effectively blanking the category.

The flash behavior ("Category no longer valid" → "Missing category") occurs because:

1. The optimistic violation handling in Duplicate.ts:377-386 only removes DUPLICATED_TRANSACTION violations — it never calls getViolationsOnyxData to recompute category violations
2. The pre-existing categoryOutOfPolicy violation persists briefly in optimistic state
3. The backend response then returns missingCategory (since the category is now empty), replacing the stale violation

What changes do you think we should make in order to solve the problem?

In compareDuplicateTransactionFields at src/libs/TransactionUtils/index.ts:2466-2476, add a fallback else clause for the category field so that when categories differ but no enabled categories are available for selection, the first transaction's category is preserved in keep rather than being silently dropped:

} else if (fieldName === 'category') {
    // ... existing availableCategories logic ...
    if (!areAllFieldsEqualForKey && policy?.areCategoriesEnabled && (availableCategories.length > 1 || ...)) {
        change[fieldName] = [...availableCategories, ...];
    } else if (areAllFieldsEqualForKey) {
        keep[fieldName] = firstTransaction?.[keys[0]] ?? firstTransaction?.[keys[1]];
+   } else {
+       // Fallback: preserve the first transaction's category (even if disabled)
+       // to avoid blanking it during duplicate resolution
+       keep[fieldName] = firstTransaction?.[keys[0]] ?? firstTransaction?.[keys[1]];
    }
}

This ensures the kept transaction retains its original category (even if disabled) rather than having it silently cleared to an empty string. The existing categoryOutOfPolicy violation will correctly show "Category no longer valid" consistently.

Note: The same pattern may affect the tag field at lines 2486-2496 (non-multi-level tags have a similar gap). Consider applying the same fallback there for consistency.

What alternative solutions did you explore? (Optional)

1. Include disabled categories in change for user selection: This would present the user with disabled category options during duplicate review. However, this adds UI complexity and the user shouldn't need to choose between disabled categories.

2. Call getViolationsOnyxData in resolveDuplicates optimistic data: This would fix the violation flash but not the underlying category-blanking issue. It addresses a symptom, not the root cause.

3. Default to the kept transaction's original category in buildMergeDuplicatesParams: Instead of reviewDuplicates?.category ?? '', fall back to the original transaction's category. This is more of a safety net but the real fix belongs in compareDuplicateTransactionFields where the data is first computed.

---

Confidence: High — code evidence traces the full data flow from compareDuplicateTransactionFields → REVIEW_DUPLICATES → buildMergeDuplicatesParams → optimistic update with empty category.

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @bernhardoj (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022028951627042054896

[melvin-bot]

@heyjennahay @bernhardoj this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!