[Exploratory] Scan - Missing category error persists on the expense details page after paying the expense

[applause-bot]

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.4.1-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-40472/folder/13176933/41237714/1471639381?sort=%2Bidentifier
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 15.4.1 Safari/Chrome, iPhone 13 iOS 26.5
App Component: Money Requests

Action Performed:

1. Go to https://staging.new.expensify.com
2. As an employee, create a scan receipt in the workspace chat
3. While the receipt is scanning - navigate to the request conversation
4. Manually edit the amount field
5. Submit the expense
6. As the admin - Mark the expense as paid

Expected Result:

If the expense is paid with empty fields, the error/red dot should be dismissed from the report preview, expense conversation and LHN

Actual Result:

Missing category error persists on the expense details page after paying 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

To be added by Applause Leads

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7175834

[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/94fa910691555d706232530ee4208194e419c5fcca7f21591baecdedc6a8f644

[trasnake87]

Proposal

What is the root cause

The "Missing category" red-dot on the expense details page is driven by transactionViolations stored in ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS. These violations reach the UI through useTransactionViolations (src/hooks/useTransactionViolations.ts:10) → getVisibleTransactionViolations → shouldShowViolation in src/libs/TransactionUtils/index.ts:1666.

The root cause is a missing settled-report guard in shouldShowViolation. The RTER violation already has this guard at line 1686:

return (isSubmitter || isInstantSubmitEnabled(policy)) && (shouldShowRterForSettledReport || !isSettled(iouReport));

But MISSING_CATEGORY at line 1697 only guards against the auto-categorization analysis window:

if (violationName === CONST.VIOLATIONS.MISSING_CATEGORY && isCategoryBeingAnalyzed(transaction)) {
    return false;
}

There is no isSettled check. So after a receipt is scanned, the 1-minute auto-categorization window closes, category stays empty, and the user pays — isCategoryBeingAnalyzed returns false, isSettled(iouReport) returns true (statusNum === REIMBURSED), yet shouldShowViolation returns true and the violation renders in MoneyRequestView.tsx via getErrorForField('category') (line 1156).

A contributing factor: in src/libs/actions/IOU/PayMoneyRequest.ts:433–450, violations are cleared via optimisticData (only for full=true payments) but there is no corresponding successData entry. A Pusher event after the API call can re-hydrate violations from the server — the server retains missingCategory for the transaction regardless of report status — causing them to reappear even after the optimistic clear.

What changes should be made

1. Add a settled-report guard to shouldShowViolation for MISSING_CATEGORY — src/libs/TransactionUtils/index.ts:1697

// Before
if (violationName === CONST.VIOLATIONS.MISSING_CATEGORY && isCategoryBeingAnalyzed(transaction)) {
    return false;
}

// After
if (violationName === CONST.VIOLATIONS.MISSING_CATEGORY && (isCategoryBeingAnalyzed(transaction) || isSettled(iouReport))) {
    return false;
}

isSettled is already imported on line 46. This mirrors the pattern for RTER and covers all callers of shouldShowViolation uniformly — MoneyRequestView, SearchUIUtils, ViolationsUtils, and the Search list items.

2. Push violation-clearing into successData as well as optimisticData — src/libs/actions/IOU/PayMoneyRequest.ts, inside the if (full) block after line 440

// Existing (optimisticData only)
onyxData.optimisticData?.push(...optimisticTransactionViolations);

// Add to successData so a Pusher re-hydration after API success cannot restore stale violations
onyxData.successData?.push(...optimisticTransactionViolations);

This reuses the already-constructed optimisticTransactionViolations array (which sets each transaction's violation key to null via Onyx.METHOD.MERGE), cementing the cleared state once the API confirms payment.

What alternatives were explored

1. UI-only guard in MoneyRequestView — MoneyRequestView.tsx:343 already computes isSettled; one could short-circuit getErrorForField('category') there. This fixes the symptom in one component but leaves other callers of shouldShowViolation (Search list items, ViolationsUtils counts) still computing incorrect visibility for settled reports. The fix in shouldShowViolation is authoritative for all consumers.

2. Clear violations at the report level in the success handler — clearing all violations for every transaction in the report inside the existing successData block (around line 335) would also work, but the optimisticTransactionViolations array is already scoped to full=true inside its own block and reusing it is a one-line change without broader scope creep.

[melvin-bot]

Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

Still overdue 6 days?! Let's take care of this!

[melvin-bot]

Now this issue is 8 days overdue. Are you sure this should be a Daily? Feel free to change it!

[melvin-bot]

12 days overdue now... This issue's end is nigh!