[$250] Categories -The missing category error on preview appears only after opening 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.12-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #86932
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Mac 15.4.1 Safari/Chrome
App Component: Money Requests

Action Performed:

1. Go to https://staging.new.expensify.com
2. Navigate to the Workspace settings > More features
3. Disable categories
4. Create an expense in WS chat
5. Enable categories
6. Go to WS chat

Expected Result:

The missing category error should be displayed on the expense preview without opening the expense details.

Actual Result:

The missing category error on the preview appears only after 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

Bug7184205_1781750454261.Recording__2447.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022067592496281050420
• Upwork Job ID: 2067592496281050420
• Last Price Increase: 2026-06-18

Issue Owner

Current Issue Owner: @mukhrr

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

[MelvinBot]

Proposal

What is the root cause of that problem?

The app already recomputes transaction violations client-side when you enable categories, so the goal of showing missingCategory on the preview without opening the expense is supported in principle. That logic shipped in PR #86932 and is present in the tested v9.4.12-0 build — so this is a remaining gap in that recompute, not a missing feature.

When you enable categories, enablePolicyCategories optimistically sets requiresCategory: true and calls pushTransactionViolationsOnyxData to add the missingCategory violation to each transaction. The preview and the detail view both read the same transactionViolations Onyx key (via useTransactionViolations), so the only reason the preview stays blank is that no violation is written for that expense at toggle time.

The recompute only iterates the transactions returned by getNonInvoiceReportItemsForPolicy, which requires the report's transactions to be present in the usePolicyData → useAllReportsTransactionsAndViolations derived collection at the moment categories are toggled. The just-created WS-chat expense isn't covered by that scoped set, so it's skipped — no missingCategory is written, and the preview shows nothing. Opening the expense detail fires OpenReport, whose response carries the backend-computed violations and writes them to the same Onyx key (Report/index.ts) — which is why the violation only appears on the preview after opening the expense.

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

Broaden the scope of the optimistic recompute in enablePolicyCategories so it covers all of the policy's transactions, not only those already materialized in the usePolicyData derived collection. Concretely, in pushTransactionViolationsOnyxData / getNonInvoiceReportItemsForPolicy, source the policy's transactions from the full transaction collection (filtered by policyID) rather than only reports present in the derived value, so a freshly-created WS-chat expense is included and gets missingCategory written immediately.

What alternative solutions did you explore? (Optional)

None — the fix should stay within the existing recompute path rather than adding a new one.

Investigation details & confidence

• Confidence: Medium-high. High confidence that the preview/detail share one Onyx source and that the recompute scope (getNonInvoiceReportItemsForPolicy over usePolicyData) is the gate. Medium confidence on the exact reason the WS-chat expense is excluded from the derived set at toggle time (the REPORT_TRANSACTIONS_AND_VIOLATIONS derived value keys every loaded transaction by reportID, so this is likely a derivation/propagation timing issue rather than the report being entirely unloaded). A local repro would pin this down — please confirm whether the expense's report is absent from useAllReportsTransactionsAndViolations at the moment categories are enabled.
• Timeline: PR #86932 (commit 99e81cf) introduced this recompute and merged 2026-06-17 06:59 UTC; 9.4.12-0-staging was cut 2026-06-17 23:51 UTC — so the fix was in the build QA tested. This bug was caught during QA of that very PR (Bug source: "Pull Request QA execution", regression link → PR auto select some values of transaction after deletion one of last 2 elements #86932), confirming it's a follow-up edge case.
• All symptoms explained: error absent on preview → violation never written for that expense; appears after opening detail → OpenReport writes authoritative violations to the shared Onyx key.
• This is a frontend issue contained to the App repo — no backend change required.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/93932) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[ahmdshrif]

Proposal

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

After re-enabling Categories, an expense created while categories were off shows no "missing category" RBR on its preview. The RBR only appears after you open the expense and come back.

What is the root cause of that problem?

The preview's RBR is driven by the transaction's entry in the transactionViolations Onyx collection (TransactionPreview/index.tsx#L48). Enabling categories does optimistically recompute violations (Category.ts#L1477-L1479 → getViolationsOnyxData), so the recompute is wired correctly.

The structural bug is a predicate mismatch inside that recompute. New transactions are seeded with category = CATEGORY_DEFAULT_VALUE ('Uncategorized'), not empty (TransactionUtils#L322-L324). Everywhere else this sentinel is treated as "missing" via isCategoryMissing, which returns true for both empty and 'Uncategorized' (CategoryUtils#L131-L137). But the missingCategory add-branch tests !categoryKey instead — and 'Uncategorized' is truthy, so the branch never fires optimistically (ViolationsUtils.ts#L447-L450). The preview stays clean until OpenReport returns the backend-computed violation when you open the expense — exactly the reported symptom. Platform-agnostic (iOS + MacOS) because it is a data gap, not a render issue.

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

Make the add-branch use the same isCategoryMissing predicate the rest of the function uses, so the 'Uncategorized' sentinel is detected:

// ViolationsUtils.ts ~L448
if (!hasMissingCategoryViolation && policyRequiresCategories && isCategoryMissing(categoryKey) && !isSelfDM) {
    newTransactionViolations.push({name: 'missingCategory', type: CONST.VIOLATION_TYPES.VIOLATION, showInReview: true});
}

Regression safety: the sibling "remove" branch already keys off isCategoryInPolicy, so a valid in-policy category still clears the violation; the tag path is unaffected (it defaults to '', falsy).

What alternative solutions did you explore? (Optional)

• Compute "missing category" locally in TransactionPreviewContent. Rejected: duplicates the violations engine and diverges from backend/detail; the data gate is correct, only the predicate is wrong.
• Seed new transactions with empty category. Rejected: the 'Uncategorized' sentinel was introduced deliberately to prevent an RBR flip during backend sync; fixing the predicate keeps that benefit.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-18 12:59:57 UTC.

Proposal

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

When categories are disabled on a workspace, an expense created in the workspace chat has no category and no violation. After categories are re-enabled, the "missing category" RBR error does not show on the expense preview in the WS chat. It only appears after the user opens the expense detail (transaction thread) once.

What is the root cause of that problem?

The expense preview is not the broken layer. TransactionPreviewContent reads violations straight from Onyx via useTransactionViolations(transaction?.transactionID) and gates the red-brick-road purely on whatever is stored there — hasAnyViolations calls hasViolation(..., showInReview=true), and shouldShowRBR is derived from it:

App/src/libs/TransactionPreviewUtils.ts

Lines 415 to 426 in 5d48c19

	const hasAnyViolations =
	!!hasViolationsOfTypeNotice ||
	hasWarningTypeViolation(transaction, violations, currentUserEmail ?? '', currentUserAccountID, iouReport ?? undefined, policy) ||
	hasViolation(transaction, violations, currentUserEmail ?? '', currentUserAccountID, iouReport ?? undefined, policy, true) ||
	(isDistanceRequest(transaction) &&
	violations?.some(
	(violation) => violation.name === CONST.VIOLATIONS.MODIFIED_AMOUNT && (violation.type === CONST.VIOLATION_TYPES.VIOLATION || violation.type === CONST.VIOLATION_TYPES.NOTICE),
	));
	const hasErrorOrOnHold = hasFieldErrors || (!isFullySettled && !isFullyApproved && isTransactionOnHold);
	const hasReportViolationsOrActionErrors = hasActionWithErrorsForTransaction(iouReport?.reportID, transaction, reportActions);
	const isDEWSubmitFailed = hasDynamicExternalWorkflow(policy) && !!getMostRecentActiveDEWSubmitFailedAction(reportActions);
	const shouldShowRBR = hasAnyViolations || hasErrorOrOnHold || hasReportViolationsOrActionErrors || hasReceiptError(transaction) || isDEWSubmitFailed;

So the preview shows the error the instant a missingCategory violation with showInReview: true lands in the transactionViolations_<id> key. The problem is that nothing writes that violation when categories are re-enabled in the build that QA tested. The expense was created while requiresCategory was false, so it never had a violation, and toggling the categories feature did not optimistically recompute one. The only thing that produces the violation is the backend: when the user opens the expense, ReportActionsView fires openReport, the server recomputes violations for that report and returns missingCategory, and only then does the preview's Onyx read light up. That lazy, open-triggered server recompute is exactly why the error "appears only after opening the expense."

This was already addressed on main. enablePolicyCategories now recomputes violations optimistically the moment the feature is toggled, by running pushTransactionAutoSelectionsOnyxData + pushTransactionViolationsOnyxData over the policy's open/processing reports:

App/src/libs/actions/Policy/Category.ts

Lines 1477 to 1479 in 5d48c19

	const autoSelections = pushTransactionAutoSelectionsOnyxData(onyxData, policyData, policyUpdate, policyCategoriesUpdate);
	pushTransactionViolationsOnyxData(onyxData, policyData, policyUpdate, policyCategoriesUpdate, {}, autoSelections);

That helper merges the optimistic policy (requiresCategory: true) and walks every transaction through ViolationsUtils.getViolationsOnyxData, which appends {name: 'missingCategory', type: 'violation', showInReview: true} for an uncategorized transaction. I verified this end-to-end against Onyx by running the full enablePolicyCategories action with a category-less expense on an open report: the transactionViolations_<id> key receives [{name: 'missingCategory', type: 'violation', showInReview: true}] both in the optimistic phase and after the mocked server success — precisely the shape the preview needs. The reported repro predates this fix (it is QA of the very PR that introduced it, #86932 / #86220, which merged after v9.4.12-0 was cut), which is why it reproduces on the old staging/production build but not on current main.

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

No new UI logic is required — the preview already reacts correctly to the violation collection, and the optimistic recompute that backfills the violation now exists on main. The work is to confirm the fix on a fresh build and close the loop with regression coverage, because the existing enablePolicyCategories tests in PolicyCategoryTest.ts only assert the policy/category enabled flags and never set up a report+transaction, so the violation backfill is exercised by no test. We should add a test that seeds a category-less transaction on an open expense report under a policy with requiresCategory: false, calls enablePolicyCategories(policyData, true), and asserts the missingCategory violation is written to Onyx:

enablePolicyCategories({...policyData, categories}, true, false);
// transactionViolations_<id> should now contain:
// {name: 'missingCategory', type: 'violation', showInReview: true}

This guards the optimistic path so the preview lights up immediately on re-enable without depending on the server's open-triggered recompute, and prevents a future refactor of pushTransactionViolationsOnyxData from silently regressing it.

What alternative solutions did you explore? (Optional)

I considered changing the preview's shouldShowRBR to compute the missing-category violation locally instead of reading it from Onyx, but that duplicates ViolationsUtils logic in the view layer and diverges from every other violation the preview surfaces; driving the optimistic transactionViolations write (as the existing enablePolicyCategories recompute does) is the correct single source of truth.

[melvin-bot]

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

[melvin-bot]

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

[yusufdeveloper2903]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.