[$250] 'No Tags' filter does not show expenses that are not tagged.

[m-natarajan]

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.77-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @alannahmae1
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. log into Expensify
2. Create an Expense with a tag and delete the same
3. Go to Spend > Expenses
4. Click Filters
5. Set Tag filter to 'No Tag'
6. Save
7. View Results

Expected Result:

Any Expense without a Tag will appear when this filter is selected.

Actual Result:

The screen shows that no expenses are available.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

Recording.2877.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022056737863515856335
• Upwork Job ID: 2056737863515856335
• Last Price Increase: 2026-05-19

Issue Owner

Current Issue Owner: @KJ21-ENG

[godzillaxbox19982014-lgtm]

Proposal

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

The No tag filter is available in the expense filters, but picking it does not return expenses where the tag is actually empty.

What is the root cause of that problem?

The frontend uses CONST.SEARCH.TAG_EMPTY_VALUE (none) as the local value for the No tag option in the tag filter UI (SearchFiltersTagPage / TagSelector). That value then gets written into the search query as tag:none by buildQueryStringFromFilterFormValues.

That is fine as a UI display sentinel, but it is not being treated as the same thing as an empty transaction tag when search results are resolved. So the query ends up looking for the literal tag value none, instead of matching expenses where transaction.tag is empty / untagged.

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

Keep the No tag UI option, but normalize CONST.SEARCH.TAG_EMPTY_VALUE properly when building/handling the search filter so it matches empty tags, not a real tag called none.

I would keep the fix scoped to the search tag-filter path:

• keep showing No tag from SearchFiltersTagPage / TagSelector
• when the selected tag value is CONST.SEARCH.TAG_EMPTY_VALUE, make the search query/results treat it as the empty tag case
• preserve the current display formatting in AdvancedSearchFilters / SearchUIUtils
• add a unit test similar to the existing empty category coverage, but for tag:none, plus a case that confirms an expense with an empty tag is included

What alternative solutions did you explore? (Optional)

Changing the transaction tag value globally or changing CONST.SEARCH.TAG_EMPTY_VALUE would be riskier, because none is already used in several display/grouping paths. A targeted search-filter normalization should fix this without affecting normal tagged expenses.

[MelvinBot]

Proposal

What is the root cause of that problem?

The search filtering for expenses is entirely server-side. When the user selects "No Tag" in the filter UI, the App sends a query containing tag:none to the backend (SearchQueryUtils.ts:956), where none is a sentinel value defined as CONST.SEARCH.TAG_EMPTY_VALUE. The query AST is serialized and sent to the backend via the SEARCH API command (Search.ts:577-589), where all filtering happens.

When a user removes a tag from an expense, the App sends an empty string '' as the new tag value via UPDATE_MONEY_REQUEST_TAG (UpdateMoneyRequest.ts:427-447). The backend's search engine likely does not match transactions whose tag was changed from a non-empty value to an empty string against the tag:none filter — there may be a difference in how the DB represents "never had a tag" (NULL) versus "had a tag removed" (empty string), and the search logic only matches one representation.

Evidence that the backend uses multiple representations: the App's result-handling code (SearchUIUtils.ts:3232-3238) maps both '' and '(untagged)' from backend responses to the none sentinel, confirming the backend returns different values for empty tags.

This appears to be a backend/internal issue. A separate internal investigation is needed.

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

The backend search logic needs to be updated so that the tag:none filter matches ALL representations of an untagged transaction — including NULL, empty string '', and '(untagged)'. This is a backend fix in the search query engine's tag filter predicate.

What alternative solutions did you explore? (Optional)

A frontend workaround is not viable since the search filtering is entirely server-side — the App correctly sends tag:none in the query and the backend is responsible for interpreting it.

Related issues

• [$250] Expense - The 'Tag no longer valid' violation appears after deleting the only tag #88338 — "The 'Tag no longer valid' violation appears after deleting the only tag" — related tag deletion behavior

---

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]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-19 14:22:17 UTC.

Proposal

What is the root cause of that problem?

Search filtering for Spend → Expenses is server-driven. Selecting No Tag stores tag: ['none'] (where 'none' is the App-side display sentinel CONST.SEARCH.TAG_EMPTY_VALUE) in SEARCH_ADVANCED_FILTERS_FORM, and buildQueryStringFromFilterFormValues serializes it through the generic multi-value tag path here:

App/src/libs/SearchQueryUtils.ts

Lines 928 to 957 in 1fc7d1d

	if (
	(filterKey === FILTER_KEYS.CATEGORY ||
	filterKey === FILTER_KEYS.CARD_ID ||
	filterKey === FILTER_KEYS.TAX_RATE ||
	filterKey === FILTER_KEYS.EXPENSE_TYPE ||
	filterKey === FILTER_KEYS.TAG ||
	filterKey === FILTER_KEYS.CURRENCY ||
	filterKey === FILTER_KEYS.PURCHASE_CURRENCY ||
	filterKey === FILTER_KEYS.FROM ||
	filterKey === FILTER_KEYS.TO ||
	filterKey === FILTER_KEYS.FEED ||
	filterKey === FILTER_KEYS.IN ||
	filterKey === FILTER_KEYS.ASSIGNEE ||
	filterKey === FILTER_KEYS.POLICY_ID ||
	filterKey === FILTER_KEYS.HAS ||
	filterKey === FILTER_KEYS.IS ||
	filterKey === FILTER_KEYS.EXPORTER ||
	filterKey === FILTER_KEYS.EXPORTED_TO ||
	filterKey === FILTER_KEYS.ATTENDEE ||
	filterKey === FILTER_KEYS.COLUMNS ||
	filterKey === FILTER_KEYS.WITHDRAWAL_STATUS) &&
	Array.isArray(filterValue) &&
	filterValue.length > 0
	) {
	const filterValueArray = [...new Set<string>(filterValue)];
	const keyInCorrectForm = (Object.keys(CONST.SEARCH.SYNTAX_FILTER_KEYS) as FilterKeys[]).find((key) => CONST.SEARCH.SYNTAX_FILTER_KEYS[key] === filterKey);
	if (keyInCorrectForm) {
	return `${prefix}${CONST.SEARCH.SYNTAX_FILTER_KEYS[keyInCorrectForm]}:${filterValueArray.map(sanitizeSearchValue).join(',')}`;
	}

That emits the literal token tag:none. The backend tag filter is a value-equality predicate (same family as tag:Project A), so tag:none matches only transactions whose tag is literally the string "none" — not transactions where the tag is empty/NULL/(untagged).

The same broken token is produced from a second App-side site — the No Tag group drill-down in group-by-tag layout — confirming this is a query-construction issue rather than an isolated UI path:

App/src/libs/SearchUIUtils.ts

Lines 3225 to 3239 in 1fc7d1d

	const tagGroup = data[key] as SearchTagGroup;
	const transactionsQueryJSON =
	queryJSON && tagGroup.tag !== undefined
	? buildSpecificGroupQuery(
	queryJSON,
	CONST.SEARCH.SYNTAX_FILTER_KEYS.TAG,
	tagGroup.tag === '' || tagGroup.tag === '(untagged)' ? CONST.SEARCH.TAG_EMPTY_VALUE : tagGroup.tag,
	)
	: undefined;
	// Format the tag name - use translated "No tag" for empty values so it sorts alphabetically
	const rawTag = tagGroup.tag;
	const isEmptyTag = !rawTag || rawTag === CONST.SEARCH.TAG_EMPTY_VALUE || rawTag === '(untagged)';
	const formattedTag = isEmptyTag ? translate('search.noTag') : getCommaSeparatedTagNameWithSanitizedColons(rawTag);

Symmetry with the category fix: PR #76840 (merged 2025-12-09, "Remove 'Uncategorized' from the filters when there's no category") simplified the frontend to send just category:none because "the logic for category:none was moved to the backend". The equivalent backend treatment for tag:none was never landed — so on the App side none for tag is still being shipped as a plain value, exactly like a real tag name.

A frontend predicate already exists for the "row has no tag" semantics — the negated has filter, documented to users in en.ts:9135 (hasFilterNegation): -has:tag. It is structural ("this transaction has no tag column populated"), not a value match, so it does not depend on what sentinel string the backend stores for empty tags ('', NULL, (untagged), etc.). This is exactly the predicate we need.

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

Route a lone No Tag selection through -has:tag at serialization time, and round-trip it back on parse so the Tag chip still says "No Tag". Three small, scoped edits — no constant churn, no behavior change for any real tag value:

1. In buildQueryStringFromFilterFormValues (SearchQueryUtils.ts ~L928-L957), before the generic tag: join, peel TAG_EMPTY_VALUE out of the array. If the remainder is empty, emit ${prefix}-has:tag; if not, emit tag:<real values> AND ${prefix}-has:tag is only added when the form contained just the empty sentinel (mixed selections fall back to the current path — the mixed-OR case requires a backend predicate change and is out of scope for this fix):

                if (keyInCorrectForm) {
+                   if (filterKey === FILTER_KEYS.TAG && filterValueArray.length === 1 && filterValueArray[0] === CONST.SEARCH.TAG_EMPTY_VALUE) {
+                       return `${prefix}-${CONST.SEARCH.SYNTAX_FILTER_KEYS.HAS}:${CONST.SEARCH.HAS_VALUES.TAG}`;
+                   }
                    return `${prefix}${CONST.SEARCH.SYNTAX_FILTER_KEYS[keyInCorrectForm]}:${filterValueArray.map(sanitizeSearchValue).join(',')}`;
                }

2. In buildFilterFormValuesFromQuery (SearchQueryUtils.ts ~L1098-L1100), after the HAS branch populates hasNot: ['tag'], additionally seed form.tag = [TAG_EMPTY_VALUE] when that is the only hasNot value — so reopening the Tag filter chip still shows "No Tag" selected and mapFiltersFormToLabelValueList still renders the Tag: No tag chip via getDisplayValue (SearchUIUtils.ts:4938-4948, which already maps TAG_EMPTY_VALUE → translate('search.noTag')).

3. In SearchUIUtils.getTagSections (~L3225-L3239), when building the drill-down query for the No Tag group, replace buildSpecificGroupQuery(..., SYNTAX_FILTER_KEYS.TAG, TAG_EMPTY_VALUE) with a small variant that pushes a negated has:tag filter onto flatFilters instead (or call a thin wrapper buildNoTagGroupQuery). Same tag === '' || tag === '(untagged)' detection — different emitted token. This keeps clicking the No Tag group consistent with the chip filter.

No changes to CONST.SEARCH.TAG_EMPTY_VALUE or any tag === TAG_EMPTY_VALUE equality check (TagSelector display, getColumnsToShow, isTagMissing, sortOptionsWithEmptyValue all keep working unchanged). Unit coverage in tests/unit/Search/SearchQueryUtilsTest.ts:

• buildQueryStringFromFilterFormValues({type: 'expense', tag: [TAG_EMPTY_VALUE]}) → contains -has:tag, no tag:none.
• buildFilterFormValuesFromQuery(buildSearchQueryJSON('type:expense -has:tag')) → tag: [TAG_EMPTY_VALUE].
• A real tag still serializes as tag:Engineering.

What alternative solutions did you explore? (Optional)

• Cascade-clear transaction.tag when a workspace tag is deleted (proposed by another contributor). This is a real product issue (orphaned tag strings after deletePolicyTags), but it only addresses one specific way an expense ends up "untagged in the user's mind" — it does not fix the more common path where the user removed the tag from the expense (setMoneyRequestTag(id, '') → tag = '' server-side). The issue title is the general case ("expenses that are not tagged"), and the issue body's "Expected Result: Any Expense without a Tag will appear" matches the general predicate, not the orphan-only sub-case. The orphan-cascade fix can be tracked separately; it is not a substitute for fixing the No Tag filter itself.

• Server-only fix (treat tag:none symmetrically to category:none): correct long-term, and the right place for the mixed-selection case ("tag = X OR no tag"). It needs backend work and ships independent of this PR. The -has:tag route lets the App fix the user-visible bug today without waiting on that.

• Bring back the pre-Remove 'Uncategorized' from the filters when theres no category #76840 comma-list pattern (TAG_EMPTY_VALUE: 'none,(untagged)'): would have to round-trip through every equality check site (tag === TAG_EMPTY_VALUE in TagSelector, getColumnsToShow, isTagMissing, sortOptionsWithEmptyValue, the two (untagged) checks in SearchUIUtils). Higher blast radius, and still doesn't help new-dot expenses with tag === ''.

[melvin-bot]

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

[mukhrr]

Proposal

What is the root cause of that problem?

The repro is: tag an expense, then delete that tag from the workspace, then filter Search by No Tag.

When you delete a workspace tag, deletePolicyTags only mutates the policy tag list (marks the tag enabled: false / pendingAction: DELETE) and refreshes violations via pushTransactionViolationsOnyxData. It never clears the deleted tag value off the transactions that still reference it, so the expense keeps an orphaned tag string pointing at a tag that no longer exists.

The Search "No Tag" filter is built correctly — selecting it produces the query tag:none (CONST.SEARCH.TAG_EMPTY_VALUE), the same token the grouped/untagged path already relies on in SearchUIUtils.getTagSections. tag:none matches only expenses whose tag is actually empty. The orphaned-tag expense has a non-empty tag, so it's never classified as untagged and the results screen shows "no expenses available".

So the bug is not in the Search query construction — it's that deleting a workspace tag doesn't make the expenses that used it become genuinely untagged.

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

Extend deletePolicyTags to also push optimistic transaction updates that clear tag on transactions whose tag is one of the deleted tags, reusing the same cascade pattern the action already uses for violations. No new API params — the existing tags payload is enough for the backend to derive which transactions to clear.

  const onyxData: OnyxData<typeof ONYXKEYS.COLLECTION.POLICY_TAGS> = {
      optimisticData: [ /* ...existing POLICY_TAGS merge... */ ],
      ...
  };

+ // An expense that used a now-deleted tag must become genuinely untagged,
+ // otherwise the Search "No Tag" (tag:none) filter can never surface it.
+ const deletedTagsSet = new Set(tagsToDelete);
+ for (const transaction of Object.values(allTransactions ?? {})) {
+     if (!transaction || transaction.policyID !== policyID || !deletedTagsSet.has(getTransactionTag(transaction))) {
+         continue;
+     }
+     onyxData.optimisticData?.push({
+         onyxMethod: Onyx.METHOD.MERGE,
+         key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transaction.transactionID}`,
+         value: {tag: ''},
+     });
+ }

  pushTransactionViolationsOnyxData(onyxData, policyData, {}, {}, policyTagsOptimisticData);
  API.write(WRITE_COMMANDS.DELETE_POLICY_TAGS, parameters, onyxData);

The backend DeletePolicyTags command should mirror this — clear the tag from transactions referencing the deleted tag server-side — so Search results (which come from the backend snapshot) reflect the change. Success/failure Onyx entries should be added alongside the existing ones so the optimistic clear rolls back if the request fails.

What alternative solutions did you explore? (Optional)

• Treat an out-of-policy tag as "no tag" at Search filter time (resolve tag:none to also include transactions whose tag isn't in the current policy tag list). Rejected: Search results are produced by the backend snapshot, not filtered client-side, so this wouldn't change what's returned, and it papers over stale data instead of fixing it.
• Block tag deletion while expenses still use it. Rejected: changes product behavior and doesn't help expenses tagged before the restriction.

[melvin-bot]

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

[KJ21-ENG]

Proposal

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

The Spend > Expenses advanced Tag filter has a "No Tag" option, but selecting it returns no expenses even when expenses without a tag exist.

What is the root cause of that problem?

The UI represents "No Tag" with CONST.SEARCH.TAG_EMPTY_VALUE, which is the literal string none.

The tag picker adds that sentinel as the option value:

App/src/pages/Search/SearchAdvancedFiltersPage/SearchFiltersTagPage.tsx

Lines 39 to 58 in eaaffe3

	const tagItems = useMemo(() => {
	const items = [{name: translate('search.noTag'), value: CONST.SEARCH.TAG_EMPTY_VALUE as string}];
	const uniqueTagNames = new Set<string>();
	if (policyIDs.length === 0) {
	const tagListsUnpacked = Object.values(allPolicyTagLists ?? {}).filter((item) => !!item);
	for (const tag of tagListsUnpacked.map(getTagNamesFromTagsLists).flat()) {
	uniqueTagNames.add(tag);
	}
	} else if (selectedPoliciesTagLists.length > 0) {
	for (const tag of selectedPoliciesTagLists) {
	uniqueTagNames.add(tag);
	}
	}
	items.push(...Array.from(uniqueTagNames).map((tagName) => ({name: getCleanedTagName(tagName), value: tagName})));
	return items;
	}, [allPolicyTagLists, policyIDs.length, selectedPoliciesTagLists, translate]);
	const updateTagFilter = useCallback((values: string[]) => updateAdvancedFilters({tag: values}), []);

Then buildQueryStringFromFilterFormValues() serializes tag filters through the same generic array path as real tag names:

App/src/libs/SearchQueryUtils.ts

Lines 928 to 957 in eaaffe3

	if (
	(filterKey === FILTER_KEYS.CATEGORY ||
	filterKey === FILTER_KEYS.CARD_ID ||
	filterKey === FILTER_KEYS.TAX_RATE ||
	filterKey === FILTER_KEYS.EXPENSE_TYPE ||
	filterKey === FILTER_KEYS.TAG ||
	filterKey === FILTER_KEYS.CURRENCY ||
	filterKey === FILTER_KEYS.PURCHASE_CURRENCY ||
	filterKey === FILTER_KEYS.FROM ||
	filterKey === FILTER_KEYS.TO ||
	filterKey === FILTER_KEYS.FEED ||
	filterKey === FILTER_KEYS.IN ||
	filterKey === FILTER_KEYS.ASSIGNEE ||
	filterKey === FILTER_KEYS.POLICY_ID ||
	filterKey === FILTER_KEYS.HAS ||
	filterKey === FILTER_KEYS.IS ||
	filterKey === FILTER_KEYS.EXPORTER ||
	filterKey === FILTER_KEYS.EXPORTED_TO ||
	filterKey === FILTER_KEYS.ATTENDEE ||
	filterKey === FILTER_KEYS.COLUMNS ||
	filterKey === FILTER_KEYS.WITHDRAWAL_STATUS) &&
	Array.isArray(filterValue) &&
	filterValue.length > 0
	) {
	const filterValueArray = [...new Set<string>(filterValue)];
	const keyInCorrectForm = (Object.keys(CONST.SEARCH.SYNTAX_FILTER_KEYS) as FilterKeys[]).find((key) => CONST.SEARCH.SYNTAX_FILTER_KEYS[key] === filterKey);
	if (keyInCorrectForm) {
	return `${prefix}${CONST.SEARCH.SYNTAX_FILTER_KEYS[keyInCorrectForm]}:${filterValueArray.map(sanitizeSearchValue).join(',')}`;
	}

So the selected "No Tag" filter becomes tag:none. The search parser treats that as a normal equality filter for a tag named none, not as "missing tag". Untagged transactions use an empty tag value in App code:

App/src/libs/TransactionUtils/index.ts

Lines 1378 to 1389 in eaaffe3

	/**
	* Return the tag from the transaction. When the tagIndex is passed, return the tag based on the index.
	* This "tag" field has no "modified" complement.
	*/
	function getTag(transaction: OnyxInputOrEntry<Transaction>, tagIndex?: number): string {
	if (tagIndex !== undefined) {
	const tagsArray = getTagArrayFromName(transaction?.tag ?? '');
	return tagsArray.at(tagIndex) ?? '';
	}
	return transaction?.tag ?? '';
	}

That is why the backend/search result set is empty: we are asking for expenses tagged with the literal value none, instead of expenses that do not have a tag.

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

Special-case CONST.SEARCH.TAG_EMPTY_VALUE when building/searching tag filters instead of letting it pass through as a real tag name.

Concretely, update the search query construction in src/libs/SearchQueryUtils.ts so when the advanced tag filter contains only CONST.SEARCH.TAG_EMPTY_VALUE, it emits the semantic "missing tag" search, i.e. -has:tag, rather than tag:none. Then update the query-to-form conversion so a -has:tag query round-trips back into the Tag filter as [CONST.SEARCH.TAG_EMPTY_VALUE], keeping the RHP display as "No Tag".

Keep normal tag values on the existing tag:<value> path. Add unit coverage in tests/unit/Search/SearchQueryUtilsTest.ts for:

• buildQueryStringFromFilterFormValues({type: 'expense', tag: [CONST.SEARCH.TAG_EMPTY_VALUE]}) producing a missing-tag query, not tag:none.
• buildFilterFormValuesFromQuery(buildSearchQueryJSON('type:expense -has:tag'), ...) restoring the "No Tag" tag filter.
• Existing real tag filters still serializing as tag:Engineering and validating against policy tags.

What alternative solutions did you explore? (Optional)

We could normalize tag:none only at backend serialization time, but that would leave saved/search URLs containing a misleading literal-tag query. We could also map the sentinel to tag:(untagged), since search grouping already recognizes backend untagged groups, but -has:tag is the clearer search syntax and matches the existing Has filter semantics for "does not have a tag".

[github-actions]

⚠️ @yusufdeveloper2903 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).