Category - Parent category is separated from subcategories when searched

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: 9.3.38-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #83200
Email or phone of affected tester (no customers): sdjsdjosijnsodiosd@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

Create both categories - D and D:E:F

Go to staging.new.expensify.com
Go to workspace chat.
Click + > Create expense > Manual.
Enter amount > Next.
Click Category.
Select D.
Click Category.
On the search field, type D.

Expected Result:

Parent category (D) and subcategories (E and F) will be arranged together.

Actual Result:

Parent category (D) and subcategories (E and F) are separated by Advertising category.

Workaround:

Unknown

Platforms:

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

You have been assigned to this deploy blocker because you recently merged this PR: #83200

💬 A slack conversation has been started in #expensify-open-source

👋 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:

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

@ijmalik

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #83200 - "Multi-level categories with colons are shown with hierarchical indentation" by @ijmalik (High confidence)
Related Issues: #82068 (original issue that PR #83200 was fixing)

Recommendation: REVERT

PR #83200 should be reverted. While it successfully added hierarchical indentation for category display, it inadvertently broke the search functionality by removing the flat one-line display mode that was previously used for search results.

Labels: No label changes needed - keeping DeployBlockerCash as this is a frontend App bug that requires an App PR revert/fix.

📋 Detailed Analysis

Evidence

PR #83200 modified src/libs/CategoryOptionListUtils.ts to add hierarchical indentation for multi-level categories. The PR removed the isOneLine parameter from the getCategoryOptionTree() function, which previously allowed categories to be displayed in two modes:

Hierarchical mode (with indentation) - for normal category list display
One-line mode (flat) - for search results

After the PR, only hierarchical mode exists, which is now used for ALL displays including search results.

Verification

The files modified by PR #83200:

src/CONST/index.ts - Changed PARENT_CHILD_SEPARATOR from ": " to ":"
src/libs/CategoryOptionListUtils.ts - Removed isOneLine parameter and one-line display logic
tests/unit/CategoryOptionListUtilsTest.ts - Updated tests

The bug occurs in the search flow (lines 119-135 of CategoryOptionListUtils.ts):

User searches for "D"
tokenizedSearch returns matching categories: "D", "D:E:F", "Advertising"
getCategoryOptionTree now always uses hierarchical mode
It creates separate entries for parent "D" and children "D:E", "D:E:F"
Alphabetical sorting places "Advertising" between "D" and "D:E"
Result: Parent and subcategories are separated

Root Cause

The PR assumed hierarchical indentation should be used everywhere, but search results need a flat display to keep parent categories together with their children. When hierarchical mode is used with alphabetical sorting, unrelated categories can appear between a parent and its subcategories.

Before PR #83200: Search used flat one-line mode

D
D:E:F
Advertising

After PR #83200: Search uses hierarchical mode with alphabetical sorting

D (parent)
Advertising (alphabetically between D and D:E)
E (child of D, displayed as D:E)
F (child of D:E, displayed as D:E:F)

Proposal

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

When a user selects a parent category (e.g. "D") and then searches for it, the parent category and its subcategories (from "D:E:F") are separated by unrelated categories like "Advertising" in the search results. They should be grouped together.

What is the root cause of that problem?

The bug is in getCategoryListSections in src/libs/CategoryOptionListUtils.ts:120. When searching with a selected category, the code prepends selectedOptionsWithDisabledState before enabledCategories:

const categoriesForSearch = [...selectedOptionsWithDisabledState, ...enabledCategories];

enabledCategories comes from sortCategories which maintains correct hierarchical order: [Advertising, D, D:E:F]. But prepending the selected "D" creates: [D(selected), Advertising, D(duplicate), D:E:F].

tokenizedSearch preserves this order (all items match "d" via substring — including "Advertising"). Then getCategoryOptionTree iterates the results and uses a Map for insertion-order tracking. It processes:

"D" (selected) → inserts into Map
"Advertising" → inserts after D
"D" (duplicate) → already in Map, skipped
"D:E:F" → "D" already exists (skip), inserts "D:E" and "D:E:F" after Advertising

Final display order: D, Advertising, E, F — subcategories are separated from their parent.

This is a regression from PR #83200 which introduced hierarchical splitting of colon-separated categories. Before that PR, "D:E:F" was displayed as a single flat item, so the prepend ordering didn't cause visual separation.

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

In the search block of getCategoryListSections (src/libs/CategoryOptionListUtils.ts, lines 119–136), after tokenizedSearch returns filtered results, deduplicate by name and re-sort through sortCategories to restore hierarchical grouping. Then re-apply isSelected (since sortCategories doesn't preserve that property). This ensures parent categories always stay adjacent to their subcategories in search results regardless of selected state.

What alternative solutions did you explore? (Optional)

Remove the prepend entirely — Don't include selectedOptionsWithDisabledState in categoriesForSearch. This would fix the ordering but could break the case where a selected-but-disabled category should still appear in search results.
Deduplicate without re-sorting — Filter duplicates from enabledCategories before prepending. This prevents the duplicate "D" but still leaves selected "D" before Advertising, so subcategories from "D:E:F" would still appear after Advertising. Doesn't fully fix the issue.

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.

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

Chrome / v9.3.38-1
Issue is still reproduce

Screen.Recording.2026-03-16.at.21.55.37.mp4

@IuliiaHerets

@IuliiaHerets are you sure this is actually still reproducible? This behavior looks very different than the original screen recording.

@yuwenmemon

@yuwenmemon you are right, the issue is not reproduced.
Sorry for confusing

No worries at all - thanks! Closing

Resolved: Category - Parent category is separated from subcategories …

Deploy Blocker ##91133 was identified to be related to the PR ##85448 that attempted to fix this issue.

Navigation Menu

Repository navigation

Category - Parent category is separated from subcategories when searched #85364

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

🔍 Investigation Summary

Recommendation: REVERT

Evidence

Verification

Root Cause

Proposal

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

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Category - Parent category is separated from subcategories when searched #85364

Description

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Activity

melvin-bot commented on Mar 16, 2026

melvin-bot commented on Mar 16, 2026

github-actions commented on Mar 16, 2026

OSBotify commented on Mar 16, 2026

🔍 Investigation Summary

Recommendation: REVERT

Evidence

Verification

Root Cause

MelvinBot commented on Mar 16, 2026

Proposal

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

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

melvin-bot commented on Mar 16, 2026

IuliiaHerets commented on Mar 16, 2026

yuwenmemon commented on Mar 16, 2026

IuliiaHerets commented on Mar 16, 2026

yuwenmemon commented on Mar 16, 2026

lanitochka17 commented on May 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions