[Due for payment 2026-06-03] [$250] Expense - Uncategorized category disappears after selection but treats it as existing category

[lanitochka17]

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.74
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #86177
Email or phone of affected tester (no customers): dreamnitethedragon+vegst@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redmi note 10s android 13
App Component: Workspace Settings

Action Performed:

1. Launch app
2. Open workspace chat
3. Create a manual expense with category and merchant
   4.Open the expense and split the expense
4. Open the split expense- amount - category - plus sign - add a category "uncategorized"
5. Save the split
6. Note missing category shown & system message "changed the category to "Uncategorized" (previously "Fees")"
7. Open the category and select uncategorized category from list
8. Note missing category is shown & system message shows "changed the expense.
9. Tap category - plus - add uncategorized category again
10. Note category name already exists error shown

Expected Result:

Uncategorized category should behave consistently across all flows.

If selected successfully, it should remain visible in category row.

Actual Result:

Selected Uncategorized category is not displayed in category row.

System messages indicate category change succeeded.

App prevents recreating Uncategorized because it already exists.

Category handling behaves inconsistently across flows.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7153820_1778749623623.Screenrecorder-2026-05-14-14-24-26-455.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022054971081155690061
• Upwork Job ID: 2054971081155690061
• Last Price Increase: 2026-05-14
• Automatic offers:
• FitseTLT | Contributor | 111463823

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

What is the root cause of that problem?

The isCategoryMissing() function treats the string "Uncategorized" as equivalent to having no category, because it matches CONST.SEARCH.CATEGORY_DEFAULT_VALUE. This causes every display location to replace a legitimately selected "Uncategorized" category with an empty string.

The function is called in multiple display paths:

• MoneyRequestView.tsx:412 — expense detail view
• IOURequestStepCategory.tsx:94 — category picker
• TransactionPreviewUtils.ts:419 — transaction preview
• CategoryCell.tsx:13 — search results

All of these set categoryForDisplay = '' when the category is "Uncategorized". Meanwhile, the system message in ModifiedExpenseMessage.ts uses the raw value, so it correctly shows "changed the category to Uncategorized" — creating the inconsistency reported in the issue.

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

isCategoryMissing() should only treat "Uncategorized" as missing in search/filter contexts (where CATEGORY_DEFAULT_VALUE was intended to apply), not when displaying a user's actual category selection.

The fix should modify the display call sites to distinguish between a real workspace category named "Uncategorized" and the absence of a category. One approach: pass the workspace's policyCategories into the display logic and only blank the value if "Uncategorized" is not an actual enabled category in the policy. Alternatively, refine isCategoryMissing to accept an optional policyCategories parameter — if "Uncategorized" exists as a real policy category, return false.

What alternative solutions did you explore? (Optional)

• Removing the CATEGORY_DEFAULT_VALUE check entirely from isCategoryMissing — this could break search filtering behavior where "Uncategorized" is used as a placeholder for "no category."
• Renaming the internal default to a non-user-visible sentinel value — higher risk of regressions across the codebase.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

A workspace category can legitimately be named Uncategorized. But the shared helper isCategoryMissing treats the literal string "Uncategorized" as "no category":

function isCategoryMissing(category: string | undefined): boolean {
    if (!category) {
        return true;
    }
    return category === CONST.SEARCH.CATEGORY_EMPTY_VALUE || category === CONST.SEARCH.CATEGORY_DEFAULT_VALUE;
}

CONST.SEARCH.CATEGORY_DEFAULT_VALUE is the string 'Uncategorized'. So once a transaction's category equals "Uncategorized", every consumer of isCategoryMissing renders it as empty:

• MoneyRequestView.tsx#L411-L412 — categoryForDisplay = isCategoryMissing(category) ? '' : category → the category row in the expense view shows blank.
• IOURequestStepCategory.tsx#L94, TransactionPreviewUtils.ts#L419, CategoryCell.tsx, TransactionItemRow — same blank rendering in the LHN preview and lists.

Meanwhile the category genuinely exists in policyCategories, so the system message (built from the raw value) correctly says "changed the category to Uncategorized", and re-creating it from the + flow correctly errors with "category already exists". Hence the inconsistency in the report: stored fine, message fine, but the row is blank.

This is a regression from PR #76840 (commit 17a2e24cf8d), which added the CATEGORY_DEFAULT_VALUE check. That commit's own test (ReportLayoutUtilsTest.ts) shows the intent: the "Uncategorized" sentinel is what the backend sends as a grouping key for un-categorized transactions in groupTransactionsByCategory — it was never meant to apply to a real expense's category field. Baking the literal into the shared helper leaked that grouping-only sentinel into every expense-display path.

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

Move the "Uncategorized" sentinel handling out of the shared helper and into the one place that actually receives it — report grouping.

1. In CategoryUtils.ts, revert isCategoryMissing so it only treats the true empty sentinel ('none') as missing:

 function isCategoryMissing(category: string | undefined): boolean {
     if (!category) {
         return true;
     }
-    return category === CONST.SEARCH.CATEGORY_EMPTY_VALUE || category === CONST.SEARCH.CATEGORY_DEFAULT_VALUE;
+    return category === CONST.SEARCH.CATEGORY_EMPTY_VALUE;
 }

2. In ReportLayoutUtils.groupTransactionsByCategory, keep collapsing the backend's "Uncategorized" grouping key into the empty group locally:

     for (const transaction of transactions) {
         const category = getCategory(transaction);
-        const categoryKey = isCategoryMissing(category) ? '' : category;
+        const categoryKey = isCategoryMissing(category) || category === CONST.SEARCH.CATEGORY_DEFAULT_VALUE ? '' : category;

This restores PR #76840's behavior exactly where it was intended (the ReportLayoutUtilsTest case with category: 'Uncategorized' still passes), while every expense-display path now shows a real Uncategorized category like any other category name. Stored value, system message, "already exists" guard, and the visible row all agree.

What alternative solutions did you explore? (Optional)

Add an opt-in parameter — isCategoryMissing(category, {treatDefaultAsMissing = false}) — and pass true only from groupTransactionsByCategory. It works, but it bolts a search/grouping concern onto a helper used by ~10 unrelated expense-display call sites; inlining the one-line check at the single real consumer is narrower and leaves the shared helper with a single clear meaning.

[mukhrr]

Proposal

What is the root cause of that problem?

CategoryUtils.isCategoryMissing treats the literal string "Uncategorized" (the search/grouping sentinel CONST.SEARCH.CATEGORY_DEFAULT_VALUE) as if the transaction had no category at all:

App/src/libs/CategoryUtils.ts

Lines 131 to 137 in 1b89b63

	function isCategoryMissing(category: string | undefined): boolean {
	if (!category) {
	return true;
	}
	return category === CONST.SEARCH.CATEGORY_EMPTY_VALUE || category === CONST.SEARCH.CATEGORY_DEFAULT_VALUE;
	}

App/src/CONST/index.ts

Lines 8018 to 8019 in 1b89b63

	CATEGORY_EMPTY_VALUE: 'none',
	CATEGORY_DEFAULT_VALUE: 'Uncategorized',

CATEGORY_EMPTY_VALUE = 'none' and CATEGORY_DEFAULT_VALUE = 'Uncategorized' are only meant as display sentinels in search/grouping results — they label a bucket of un-categorized expenses, not real category data on a transaction. But once isCategoryMissing was widened to match the "Uncategorized" string itself, every consumer that renders the actual transaction starts misbehaving as soon as the user creates a real policy category whose name happens to be Uncategorized:

• MoneyRequestView blanks the category cell because categoryForDisplay becomes '':
  

  App/src/components/ReportActionItem/MoneyRequestView.tsx

  Line 412 in 1b89b63

  const categoryForDisplay = isCategoryMissing(category) ? '' : category;

• TransactionItemRow, TransactionPreviewUtils, IOURequestStepCategory, and CategoryCell all do the same isCategoryMissing(...) ? '' : ... dance and hide the value (steps 7 and 9 of the repro).
• ModifiedExpenseMessage still uses the underlying string, so the system message correctly says "changed the category to Uncategorized" — which is exactly the inconsistency the reporter screenshots.
• Policy_Categories actually contains "Uncategorized", so the duplicate-name check on Create Category fires "category name already exists" (step 11).

Net effect: the value is persisted and validated as a real category everywhere except in the display layer, which silently strips it. This was introduced in PR #86177 when the === CATEGORY_DEFAULT_VALUE branch was added to isCategoryMissing to fix a search-snapshot test — the sentinel leaked out of the search context into the global utility.

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

Stop conflating the search-display sentinel with real transaction data. isCategoryMissing should only flag absent values and the dedicated empty-bucket marker ('none'):

- return category === CONST.SEARCH.CATEGORY_EMPTY_VALUE || category === CONST.SEARCH.CATEGORY_DEFAULT_VALUE;
+ return category === CONST.SEARCH.CATEGORY_EMPTY_VALUE;

A real user-created category named "Uncategorized" then renders, edits, and de-duplicates like any other category, and the search/grouping code paths that genuinely need to recognise the "Uncategorized" bucket (e.g. CategoryListItemHeader, SearchUIUtils) keep comparing to CONST.SEARCH.CATEGORY_DEFAULT_VALUE directly — they already do.

To prevent regressions, I'd also rename CATEGORY_DEFAULT_VALUE to something less ambiguous like UNCATEGORIZED_GROUP_KEY and add a unit test on isCategoryMissing asserting that the string "Uncategorized" is not treated as missing.

What alternative solutions did you explore?

1. Block users from creating a category named "Uncategorized" in WorkspaceCategoryCreatePage validation — sidesteps the collision but punishes a perfectly reasonable category name and doesn't help workspaces that already have one.
2. Display the literal "Uncategorized" string when isCategoryMissing is true instead of hiding the row — masks the symptom (the row would render) but leaves the underlying conflation in place: ModifiedExpenseMessage, TransactionItemRow, and category-validation logic would still disagree about whether the transaction has a category.
3. Namespace the sentinel by changing CATEGORY_DEFAULT_VALUE to something that can never collide with a category name (e.g. a __ prefix). Works, but the backend already returns the literal string "Uncategorized" in grouped search results, so a frontend-only rename isn't enough — the comparison still has to be search-context-aware. The minimal fix above achieves that without coordinating a wire-format change.

[dilshodmackbook-sketch]

Proposal

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

When a user creates a policy category literally named "Uncategorized" and assigns it to an expense, the category row renders empty even though the change actually succeeded (the system message correctly says "changed the category to 'Uncategorized'", and the category really does exist in the policy). The category row should show "Uncategorized" like any other category.

What is the root cause of that problem?

isCategoryMissing treats the literal string 'Uncategorized' as "no category":

https://github.com/Expensify/App/blob/main/src/libs/CategoryUtils.ts#L131-L137

function isCategoryMissing(category: string | undefined): boolean {
    if (!category) {
        return true;
    }
    return category === CONST.SEARCH.CATEGORY_EMPTY_VALUE || category === CONST.SEARCH.CATEGORY_DEFAULT_VALUE;
}

CONST.SEARCH.CATEGORY_DEFAULT_VALUE is the string 'Uncategorized':

https://github.com/Expensify/App/blob/main/src/CONST/index.ts#L8011

So for a real expense whose category is genuinely 'Uncategorized', isCategoryMissing returns true, and every display call site collapses it to an empty string — e.g. MoneyRequestView and IOURequestStepCategory:

const categoryForDisplay = isCategoryMissing(category) ? '' : category;

The other two observed behaviors are actually correct and only look inconsistent because of this: the modified-expense system message uses the raw value so it shows "Uncategorized" properly, and the "already exists" error is right — the category really was created in the policy.

The key fact is that CONST.SEARCH.CATEGORY_DEFAULT_VALUE is referenced only by isCategoryMissing — nowhere else in the app. Nothing ever assigns 'Uncategorized' as a category value: an uncategorized expense has category as ''/undefined, and the Search domain uses CATEGORY_EMPTY_VALUE ('none') as its sentinel (see SearchQueryUtils/SearchUIUtils, which use CATEGORY_EMPTY_VALUE exclusively and never CATEGORY_DEFAULT_VALUE). So the CATEGORY_DEFAULT_VALUE clause guards against a value that never occurs as data — and its only real-world effect is misclassifying a user-created category named "Uncategorized".

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

Drop the CATEGORY_DEFAULT_VALUE clause from isCategoryMissing so a real category named "Uncategorized" is no longer treated as absent:

 function isCategoryMissing(category: string | undefined): boolean {
     if (!category) {
         return true;
     }
-    return category === CONST.SEARCH.CATEGORY_EMPTY_VALUE || category === CONST.SEARCH.CATEGORY_DEFAULT_VALUE;
+    return category === CONST.SEARCH.CATEGORY_EMPTY_VALUE;
 }

This is a one-line change that fixes the category row across all ~10 call sites at once (MoneyRequestView, IOURequestStepCategory, TransactionItemRow, CategoryCell, TransactionPreviewUtils, ReportLayoutUtils, ModifiedExpenseMessage, etc.) with zero call-site edits — no behavior changes for genuinely empty categories, since !category and CATEGORY_EMPTY_VALUE ('none') still cover those. CONST.SEARCH.CATEGORY_DEFAULT_VALUE becomes unused and should be removed as follow-on cleanup.

What alternative solutions did you explore? (Optional)

• Scope the check to Search contexts via a flag — add isCategoryMissing(category, isFromSearch = true) and pass false from expense-detail call sites. This would be the right move if the backend ever returned the literal 'Uncategorized' in a search snapshot — but there's no evidence it does (Search consistently uses 'none'), so this just adds a parameter and ~10 call-site edits to defend a case that doesn't exist. The one-line removal is preferred; if reviewers want to confirm no backend response sends category: 'Uncategorized', that's a quick check before merging.
• Block users from naming a category "Uncategorized" — punishes the user for a reserved word that isn't actually reserved at the data layer, and doesn't fix the underlying misclassification.

[melvin-bot]

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

[melvin-bot]

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

[aswin-s]

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

When a user creates a split expense and adds a category named "Uncategorized" through the in-situ Add Category flow, the category is successfully stored (confirmed by the system message "changed the category to 'Uncategorized' (previously 'Fees')") but is not displayed in the category row. Additionally, attempting to add the category again fails with "category already exists," and the app treats the transaction as missing a category across all surfaces (display, violations, category analysis). This creates inconsistent behavior where the category is both saved and invisible.

Users who already have a workspace category named "Uncategorized" stored in policyCategories are also affected: every surface that calls isCategoryMissing() treats those expenses as uncategorized, so the category disappears from the UI and the transaction accumulates violations — even after a successful save.

What is the root cause of that problem?

The root cause is a collision between user-created category names and reserved sentinel values used internally by the app.

The isCategoryMissing() guard is defined in src/libs/CategoryUtils.ts:

App/src/libs/CategoryUtils.ts

Lines 131 to 137 in 5000a57

	function isCategoryMissing(category: string | undefined): boolean {
	if (!category) {
	return true;
	}
	return category === CONST.SEARCH.CATEGORY_EMPTY_VALUE || category === CONST.SEARCH.CATEGORY_DEFAULT_VALUE;
	}

It returns true whenever the category string equals CONST.SEARCH.CATEGORY_DEFAULT_VALUE ("Uncategorized") or CONST.SEARCH.CATEGORY_EMPTY_VALUE ("none"). This logic is correct and intentional — the sentinels exist to detect transactions that have no real category assigned. The problem is that the app never prevents those sentinel strings from being stored as real policyCategories entries.

The creation validator that should have caught this is in src/pages/workspace/categories/CategoryForm.tsx:

App/src/pages/workspace/categories/CategoryForm.tsx

Lines 44 to 62 in 5000a57

	(values: FormOnyxValues<typeof ONYXKEYS.FORMS.WORKSPACE_CATEGORY_FORM>) => {
	const errors: FormInputErrors<typeof ONYXKEYS.FORMS.WORKSPACE_CATEGORY_FORM> = {};
	const newCategoryName = values.categoryName.trim();
	if (!isRequiredFulfilled(newCategoryName)) {
	errors.categoryName = translate('workspace.categories.categoryRequiredError');
	} else if (policyCategories?.[newCategoryName]) {
	errors.categoryName = translate('workspace.categories.existingCategoryError');
	} else if (newCategoryName === CONST.INVALID_CATEGORY_NAME) {
	errors.categoryName = translate('workspace.categories.invalidCategoryName');
	} else if ([...newCategoryName].length > CONST.API_TRANSACTION_CATEGORY_MAX_LENGTH) {
	// Uses the spread syntax to count the number of Unicode code points instead of the number of UTF-16 code units.
	addErrorMessage(errors, 'categoryName', translate('common.error.characterLimitExceedCounter', [...newCategoryName].length, CONST.API_TRANSACTION_CATEGORY_MAX_LENGTH));
	}
	return errors;
	},
	[policyCategories, translate],
	);

It checks for empty names, duplicates in the policy, the reserved name "###", and character limits — but it does not block names that match CONST.SEARCH.CATEGORY_DEFAULT_VALUE or CONST.SEARCH.CATEGORY_EMPTY_VALUE.

Because no guard exists at write time, a user can persist "Uncategorized" into policyCategories. Every downstream consumer — MoneyRequestView, CategoryCell, TransactionItemRow, ModifiedExpenseMessage, violation logic (getViolationsOnyxData in src/libs/Violations/ViolationsUtils.ts), and category analysis (groupTransactionsByCategory in src/libs/ReportLayoutUtils.ts) — calls isCategoryMissing() and therefore treats any expense whose category field equals the sentinel as uncategorized, hiding the category and generating spurious violations.

The CategoryForm.tsx validator is the single creation path used by the workspace category add screen (the same form is rendered for both the workspace settings flow and the in-situ add-category modal). Category creation via the Expensify policy API does not use this client-side form, but that path does not accept arbitrary free-text names from end users, so it is not exposed to this bug.

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

1. Prevent future creation of sentinel-named categories

File: src/pages/workspace/categories/CategoryForm.tsx
Function: validate
Description: Extend the existing CONST.INVALID_CATEGORY_NAME check to also reject names that match the two reserved sentinel values.

} else if (
    newCategoryName === CONST.INVALID_CATEGORY_NAME ||
    newCategoryName === CONST.SEARCH.CATEGORY_DEFAULT_VALUE ||
    newCategoryName === CONST.SEARCH.CATEGORY_EMPTY_VALUE
) {
    errors.categoryName = translate('workspace.categories.invalidCategoryName');

This blocks any user-typed name that would collide with a sentinel, surfacing a clear error before the category is written to policyCategories.

2. Migrate existing sentinel-named categories in policyCategories

Any workspace that already has a category literally named "Uncategorized" or "none" stored in policyCategories will continue to exhibit the display bug until that entry is removed or renamed. Because silently mutating workspace data server-side is out of scope for a frontend fix, the recommended mitigation is to add a guard in isCategoryMissing() (src/libs/CategoryUtils.ts, lines 131–137) that checks whether the sentinel value also exists as a real key in the current workspace's policyCategories:

// src/libs/CategoryUtils.ts
function isCategoryMissing(
    category: string | undefined,
    policyCategories?: PolicyCategories,
): boolean {
    if (!category) {
        return true;
    }
    // If the category name equals a sentinel but is also a real policy category,
    // treat it as present rather than missing.
    const isSentinel =
        category === CONST.SEARCH.CATEGORY_DEFAULT_VALUE ||
        category === CONST.SEARCH.CATEGORY_EMPTY_VALUE;
    if (isSentinel && policyCategories && category in policyCategories) {
        return false;
    }
    return isSentinel;
}

All nine call-sites of isCategoryMissing() already receive or can receive policyCategories through their existing Onyx subscriptions (MoneyRequestView, getViolationsOnyxData, groupTransactionsByCategory, etc.), so the function signature change is backward-compatible: callers that do not pass policyCategories will retain the current sentinel behaviour, while callers that do pass it will correctly distinguish a real policy category from a missing one.

Blast radius: Change 1 is fully scoped to the category creation validator and has no effect on read paths. Change 2 modifies only the sentinel comparison in isCategoryMissing(); existing callers that omit policyCategories are unaffected. Together, the two changes close the write-time gap (new categories) and the read-time gap (existing categories).

What alternative solutions did you explore? (Optional)

An alternative is to rename or remove existing sentinel-named categories server-side via a migration script. This would fix all affected workspaces immediately without requiring a code change to isCategoryMissing(), but it modifies user data without consent and is out of scope for a client-side contributor fix.

Another alternative considered was updating every downstream consumer (MoneyRequestView, CategoryCell, etc.) individually to check policyCategories before calling isCategoryMissing(). This would work but scatters the fix across nine call-sites and increases the chance of a missed location; centralising the guard in isCategoryMissing() itself (Change 2 above) is strictly safer.

[github-actions]

⚠️ @mukhrr Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).