Category filter is not hidden when there are no categories in the workspace

[vincdargento]

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.66-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: https://github.com/Expensify/Expensify/issues/655397
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team

Action Performed:

1. Go to staging.new.expensify.com
2. Create a new account.
3. Create a workspace.
4. Go to workspace settings > More features.
5. Enable Tags.
6. Go to workspace settings > Categories.
7. Click More > Settings.
8. Disable Members must categorize all expenses.
9. Delete all the categories.
10. Go to Spend > Expenses.
11. Click Filters.
12. Find Category and Tag filter

Expected Result:

Both the Category and the Tag filter are hidden.

Actual Result:

Category filter is not hidden when there are no categories in the workspace

Workaround:

N/A

Platforms:

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

Screenshots/Videos

Bug7237040_1787128136942.bandicam_2026-08-19_11-28-04-748.mp4

Issue Owner

Current Issue Owner: @QichenZhu

[MelvinBot]

Proposal

What is the root cause of that problem?

useAdvancedSearchFilters never checks whether the Category filter should be displayed — the category key is simply always emitted.

Every other conditional filter row has a guard. Tags get one at src/hooks/useAdvancedSearchFilters.ts:336 (shouldDisplayTagFilter) and are dropped from the list at line 353. Tax rate, card, bank account, workspace, attendee, and report field all have equivalent guards on lines 356–376.

There is no such guard for category. The key is listed in the filter set at line 42 (plus lines 125 and 166 for the other search types) and falls straight through the .map() to the output. So the row renders regardless of how many categories exist — and even regardless of whether the Categories feature is enabled at all.

That gap is pinned by an existing test, tests/unit/hooks/useAdvancedSearchFilters.test.ts:103-115, named shows category filter when no categories are configured, which asserts the row appears even with areCategoriesEnabled: false.

I reproduced this on dev web following the exact repro steps. With zero categories and zero tags, the Tag row is correctly gone and the Category row is still there:

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

Give category the same treatment tag already has in useAdvancedSearchFilters, with one extra guard because category data loads lazily.

1. Add an areCategoriesEnabled flag to policyDerivedSelector, using isPolicyFeatureEnabled with CONST.POLICY.MORE_FEATURES.ARE_CATEGORIES_ENABLED, exactly as areTagsEnabled is derived today.
2. Add a "any categories exist" selector over ONYXKEYS.COLLECTION.POLICY_CATEGORIES, mirroring hasTagsSelector. Note that PolicyCategories is a flat Record<categoryName, PolicyCategory>, one level shallower than PolicyTagLists, so the check is a single Object.values(...).some(...) and should ignore entries pending deletion.
3. Add a selected-workspace variant using the existing generic getAllPolicyValues(policyID, ONYXKEYS.COLLECTION.POLICY_CATEGORIES, ...), matching hasSelectedPolicyTags. That helper is already used with the categories collection elsewhere, so no changes are needed there.
4. Compute shouldDisplayCategoryFilter via the existing shouldDisplayFilter helper and return early for SYNTAX_FILTER_KEYS.CATEGORY when it is false.
5. Gate the hiding on the category-load flag. This is the part that differs from tags. POLICY_CATEGORIES is not in the OpenApp payload — it is fetched only by openSearchCategoryFiltersPage, which is triggered from useLoadSearchCategoryData. Neither render site of the filter list calls that hook, so on first open the collection is legitimately empty. Hiding the row on an empty collection alone would make it unreachable forever, since opening the row is what triggers the fetch. Keep the row visible while ONYXKEYS.IS_SEARCH_FILTERS_CATEGORY_DATA_LOADED is false, and additionally kick off useLoadSearchCategoryData where the list is built so the flag actually resolves when the user opens Filters.

Only one call site consumes the hook — FilterList.tsx:107 — and both the RHP filters page and the wide-screen filters popup render through it, so this single change covers both. The filter chip row above the results needs nothing: it only emits a chip for filters that already hold a value.

Two existing tests will need updating: the shows category filter when no categories are configured test above must be inverted, and the cross-feature interaction test at line 519 asserts category is present without seeding any category data. New tests should mirror the two tag-hiding cases.

What alternative solutions did you explore? (Optional)

Check only policy.areCategoriesEnabled. Rejected — it does not fix this report. The tester left the Categories feature enabled and only deleted the categories, so the flag is still true and the row would still show. The count check is the part that matters here; the flag is worth adding alongside it for consistency with tags.

Skip the extra useLoadSearchCategoryData call and rely only on the loaded-flag guard. Zero risk of an extra API call, and self-healing, since the flag persists once the user opens the Category picker once. But it would not hide the row on a fresh session, which is the reported scenario.

Exclude the personal workspace from the count. CategorySelector filters out the personal policy when building the picker, so a strict "never show a row above an empty picker" rule would use getAvailableNonPersonalPolicyCategories instead. That needs ONYXKEYS.PERSONAL_POLICY_ID, which forces the selector out of module scope. Worth considering as a follow-up, but the tag pattern does not do this either, so I would keep the two consistent.

Additional verification details

Reproduction (dev web). Created a new workspace, enabled Tags under More features, turned off "Members must categorize all expenses", deleted all 19 default categories, then opened Search (Expenses) > Filters. The rendered list contained 32 filter keys with no tag key, and a visible Category row between Description and Reimbursable. Opening that row shows only the built-in "No category" option:

No console errors.

Why the asymmetry with tags exists. TagSelector reads POLICY_TAGS with no loading gate and there is no OpenSearchTagFiltersPage command, so tag data is always present when the filter list renders. The dedicated IS_SEARCH_FILTERS_CATEGORY_DATA_LOADED and RAM_ONLY_IS_LOADING_SEARCH_FILTERS_CATEGORY_DATA keys exist only for categories. That is why the category guard needs the extra load check that the tag guard does not.

Related issues. I scanned open issues in this repo for the same symptom and found no duplicate. #91016 ("Expense – Empty report displayed when category is disabled from another tab") touches category state in search results but is a different defect.

Deep-linking. The category filter route stays reachable by direct URL even when the row is hidden, rendering an empty picker. That is the same pre-existing behavior as the tag route, so I would treat it as out of scope here.

---

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

---

view run · no recording available

[melvin-bot]

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

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[QichenZhu]

@MelvinBot's proposal doesn't work.

[MelvinBot]

Withdrawing my proposal — QichenZhu is right

Hiding the Category row the way I described was already built, reviewed, and then deliberately removed in #96460. Commit e447a85 — "fix(search): always show category filter" — deleted the exact selectors and shouldDisplayCategoryFilter guard I proposed re-adding, along with my step 5 (commit f3dab42, "show unloaded category filter"). Today's behavior is intentional.

The reasoning on that PR, from JS00001:

Tbh I'd rather just always show the category filter with an empty state if theres no data rather than making it conditional

and dannymcclain (Design):

Yeah I agree - the filter disappearing unpredictably is pretty awful. But also, if a workspace didn't have any categories or no categories are enabled, wouldn't No category always be a valid query?

So what should happen with this issue

Option A — close as intended, and fix the inconsistency in the other direction. TagSelector always offers "No tag" exactly like CategorySelector always offers "No category". By the July reasoning, the Tag row is the one behaving wrongly. Removing the tag guard at useAdvancedSearchFilters.ts:336 is a pure deletion — no new Onyx reads, no async flip, no network cost — but it reverts #93568, so it needs Design sign-off. The TestRail case behind this report would also need updating.

Option B — if the row really must hide, it needs a backend signal. Auth would have to return a per-policy hasCategories (or category count) on the policy_ object in OpenApp/OpenSearchPage, so the client can decide synchronously. That is why the tag guard works and a category guard can't: tags are already resident, categories are fetched lazily by OpenSearchCategoryFiltersPage. This is outside the App repo and needs an internal engineer.

Why my proposal fails on its own terms, even ignoring the prior decision

• Flicker. On first open the row renders, OpenSearchCategoryFiltersPage returns, and the row vanishes under the cursor — shifting every row below it. In the wide-screen popup, selectedFilter is plain useState and is never reconciled against the visible list, so a selected-then-hidden Category row leaves the right pane rendering a selector for a row that no longer exists. This is the exact video Eskalifer1 posted on [Payment due @Eskalifer1] Search - Load categories from all workspaces #96460.
• The repro still fails. The row is visible for the whole network round-trip, which is what step 12 of the repro looks at.
• Offline it never hides. useLoadSearchCategoryData.ts:47 returns early when offline, so the loaded flag never flips.
• Once hidden, it can't come back. IS_SEARCH_FILTERS_CATEGORY_DATA_LOADED is persisted and is only ever set to true. The only caller that passes shouldRefresh: true is CategorySelector — the row you just hid. Join a workspace with categories afterwards and the row stays gone.
• Cost and shared-state hazard. Calling the loader from FilterList fires OpenSearchCategoryFiltersPage for everyone who opens Filters. That command merges name-and-enabled-only records into the shared policyCategories_ collection with no completeness marker — a known hazard on [Payment due @Eskalifer1] Search - Load categories from all workspaces #96460 that was accepted only because it required deliberately opening the Category filter.
• I also had the personal-policy exclusion wrong: a global "any categories exist" check would keep the row visible above a picker that shows only "No category", since CategorySelector filters the personal policy out.

---

Next steps: this is a product call, not a code question. If Design still holds the July position, close this and update the TestRail case (optionally taking Option A). If the expectation has changed, Option B needs an internal engineer for the Auth-side field.

---

view run

[mukhrr]

i think this can be fixed on FE

[QichenZhu]

@Expensify/design, the OP says the Category filter should be hidden when there are no categories, but this comment says it should always show. For reference, the Tag filter is only visible when there are tags. Which behaviour is correct?

[dannymcclain]

I think the behavior we decided on in the other issue is correct. @JS00001 @Expensify/design can y'all confirm that's where we landed?

[shawnborton]

Yeah that makes sense to me. So I think we can close this?

[JS00001]

I agree, that sounds right to me!