[$250] Search - Error occurs after adding "group-by: reports" to the search query

[jponikarchuk]

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.64-13
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: EDGE case. Issue to retest: #62222
Internal issue: https://github.com/Expensify/Expensify/issues/507014
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11 / Chrome, iPhone 13 / iOS 26.5, Samsung Galaxy A52 / Android 14
App Component: Search

Action Performed:

Preconditions:

• Logged in to a user that has some expenses
  Steps:
  1.Go to Spend > Expense

2. Click advance filters
3. Select From an account that you're logged in (yourself) > save the search > click view results
4. Go to search bar
5. Add query in the existing input "group-by: reports" and ente
6. Click advance filters and select save

Expected Result:

typing "group-by: reports" should show expected result and "from" filter remains applied

Actual Result:

Error occurs after adding "group-by: reports" to the search query and "from" filter disappear

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022054389470496700909
• Upwork Job ID: 2054389470496700909
• Last Price Increase: 2026-07-22

[MelvinBot]

Proposal

What is the root cause of that problem?

There are two compounding issues:

1. "reports" is not a valid groupBy value. The valid values are defined in CONST.SEARCH.GROUP_BY: from, card, withdrawal-id, category, merchant, tag, month, week, year, quarter. The PEG parser accepts any identifier as a groupBy value without validation, so group-by:reports passes parsing but fails downstream.

2. The from filter disappears because of the substitution map flow. When a user edits the search bar text, getUpdatedSubstitutionsMap re-parses the query with the autocomplete parser on every keystroke. If the parser produces incorrect or empty ranges during intermediate typing states (e.g. while typing group-by: with no value yet), it returns {} for the substitution map (line 24-26), wiping the from display-name-to-accountID mapping. When the query is subsequently submitted, the from display name can't be substituted back to an accountID, and buildFilterFormValuesFromQuery filters it out because personalDetails?.[displayName] returns undefined.

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

Two fixes:

1. Validate groupBy values at parse time or submission time. In getQueryWithUpdatedValues, after parsing the query, check if queryJSON.groupBy is a valid CONST.SEARCH.GROUP_BY value. If not, strip it from the query (or show a user-facing error) rather than submitting an invalid value that causes downstream failures.

2. Prevent the substitution map from being fully wiped. In getUpdatedSubstitutionsMap, when searchAutocompleteQueryRanges.length === 0, return the existing substitutions instead of {}. If the autocomplete parser fails to produce ranges for a partially-typed query, we should preserve the existing substitutions rather than discarding them, so that the from filter mapping survives editing.

What alternative solutions did you explore? (Optional)

• Restricting the PEG grammar to only accept valid groupBy values would catch invalid input earlier, but the grammar is also used for autocomplete suggestions, and being too restrictive there creates a poor UX for partial/in-progress typing.
• Wrapping the autocomplete parse() call in a try/catch in getUpdatedSubstitutionsMap and returning the previous substitutions on failure would be more defensive but doesn't address the root cause of "reports" being invalid.

Investigation details

Data flow that triggers the bug:

1. User has a search with from:12345 (displayed as from:"John Doe" via the substitution map)
2. User types group-by: reports in the search bar
3. During typing, getUpdatedSubstitutionsMap re-parses the query — at intermediate states (e.g., just group-by: with no value), the autocomplete parser may return zero ranges, causing the substitution map to be wiped to {}
4. On submit, getQueryWithSubstitutions can't find "John Doe" → 12345 mapping, so the display name is submitted as-is
5. buildFilterFormValuesFromQuery filters from values through personalDetails?.[id] — since the display name isn't a valid key, the from filter is silently removed
6. Additionally, groupBy:"reports" is sent to the backend API, which may return an error since "reports" is not in the valid enum

Possibly related issue: Expensify/App#89588 — "The app crashes after selecting a group on the search page" — may share underlying group-by handling issues.

---

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.

[melvin-bot]

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

[wildan-m]

Proposal

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

When a user adds group-by: reports to the existing search query (for example to a saved search filtered by From: yourself) and then clicks the Save button to open the Save search page, an error occurs and the displayed filters look wrong. The value reports is not a recognized group-by value (the recognized values are from, card, withdrawal-id, category, merchant, tag, month, week, year, quarter), so the unrecognized value flows through the rest of the search code and breaks rendering on the Save search page.

What is the root cause of that problem?

The Peggy search grammar treats groupBy as a defaultKey and accepts any value the user types — there is no validation that the value belongs to CONST.SEARCH.GROUP_BY. The grammar rule and root key list are here:

App/src/libs/SearchParser/searchParser.peggy

Line 313 in c300f98

defaultKey "default key" = @(type / status / sortBy / sortOrder / policyID / groupBy / columns / limit / view)

The valid values are defined here:

App/src/CONST/index.ts

Lines 7587 to 7598 in c300f98

	GROUP_BY: {
	FROM: 'from',
	CARD: 'card',
	WITHDRAWAL_ID: 'withdrawal-id',
	CATEGORY: 'category',
	MERCHANT: 'merchant',
	TAG: 'tag',
	MONTH: 'month',
	WEEK: 'week',
	YEAR: 'year',
	QUARTER: 'quarter',
	},

So after parsing group-by:reports, the resulting queryJSON.groupBy ends up with the literal string "reports". Most downstream code is defensive about that (for example getValidGroupBy returns undefined for unknown values):

App/src/libs/SearchUIUtils.ts

Lines 4411 to 4413 in c300f98

	function getValidGroupBy(groupBy: string | undefined): ValueOf<typeof CONST.SEARCH.GROUP_BY> | undefined {
	return groupBy && Object.values(CONST.SEARCH.GROUP_BY).includes(groupBy as ValueOf<typeof CONST.SEARCH.GROUP_BY>) ? (groupBy as ValueOf<typeof CONST.SEARCH.GROUP_BY>) : undefined;
	}

But the Save search page and the Display popup pass the raw value directly to translate() to look up the localized label, without going through getValidGroupBy. The Save search page does this when building the list of applied displays:

App/src/pages/Search/SearchSavePage.tsx

Lines 96 to 98 in c300f98

	if (searchAdvancedFiltersForm.groupBy) {
	appliedDisplays.push({label: translate('search.display.groupBy'), value: translate(`search.filters.groupBy.${searchAdvancedFiltersForm.groupBy}`)});
	}

The Display popup does the same when rendering the Group by row:

App/src/components/Search/FilterDropdowns/DisplayPopup.tsx

Line 87 in c300f98

title={groupByValue ? translate(`search.filters.groupBy.${groupByValue}`) : undefined}

Because there is no search.filters.groupBy.reports translation key (only the keys for the recognized values exist), translate() cannot resolve the path. In production and staging that triggers a Log.alert(...) call that surfaces as the error the user sees, and on development builds it throws and the React tree falls back to an error boundary which is what makes the existing from chip and the rest of the previously rendered filters appear to "disappear" along with the rest of the page content.

The translation lookup itself is here for reference:

App/src/libs/Localize/index.ts

Lines 117 to 139 in c300f98

	function translate<TPath extends TranslationPaths>(locale: Locale | undefined, path: TPath, ...parameters: TranslationParameters<TPath>): string {
	if (!locale) {
	// If no language is provided, return the path as is
	return Array.isArray(path) ? path.join('.') : path;
	}
	const translatedPhrase = memoizedGetTranslatedPhrase(locale, path, ...parameters);
	if (translatedPhrase !== null && translatedPhrase !== undefined) {
	return translatedPhrase;
	}
	// Phrase is not found in default language, on production and staging log an alert to server
	// on development throw an error
	if (Config.IS_IN_PRODUCTION || Config.IS_IN_STAGING) {
	const phraseString = Array.isArray(path) ? path.join('.') : path;
	Log.alert(`${phraseString} was not found in the ${locale} locale`);
	if (userEmail.includes(CONST.EMAIL.EXPENSIFY_EMAIL_DOMAIN)) {
	return CONST.MISSING_TRANSLATION;
	}
	return phraseString;
	}
	throw new Error(`${path} was not found in the ${locale} locale`);
	}

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

Validate group-by values once, at the boundary where the parsed query is materialized, instead of patching every consumer. The natural place to do this is getCachedSearchQueryJSON in SearchQueryUtils.ts, which is the function that turns the parser output into the cached SearchQueryJSON object that everything else consumes:

App/src/libs/SearchQueryUtils.ts

Lines 592 to 642 in c300f98

	function getCachedSearchQueryJSON(query: SearchQueryString, rawQuery?: SearchQueryString): Readonly<SearchQueryJSON> | undefined {
	const cacheKey = getBuildSearchQueryJSONCacheKey(query, rawQuery);
	if (buildSearchQueryJSONCache.has(cacheKey)) {
	return buildSearchQueryJSONCache.get(cacheKey);
	}
	try {
	const result = parseSearchQuery(query) as SearchQueryJSON;
	const flatFilters = getFilters(result);
	const rawFilterList = rawQuery ? getRawFilterListFromQuery(rawQuery) : result.rawFilterList;
	// Add the full input and hash to the results
	result.inputQuery = query;
	result.flatFilters = flatFilters;
	result.isViewExplicitlySet = rawFilterList?.some((filter) => filter.key === CONST.SEARCH.SYNTAX_ROOT_KEYS.VIEW) ?? false;
	if (result.policyID && typeof result.policyID === 'string') {
	// Ensure policyID is always an array for consistency
	result.policyID = [result.policyID];
	}
	// Normalize limit before computing hashes to ensure invalid values don't affect hash
	if (result.limit !== undefined) {
	const num = Number(result.limit);
	result.limit = Number.isInteger(num) && num > 0 ? num : undefined;
	}
	const {primaryHash, recentSearchHash, similarSearchHash} = getQueryHashes(result);
	result.hash = primaryHash;
	result.recentSearchHash = recentSearchHash;
	result.similarSearchHash = similarSearchHash;
	delete result.rawFilterList;
	if (rawQuery) {
	result.rawFilterList = rawFilterList;
	}
	if (buildSearchQueryJSONCache.size >= BUILD_SEARCH_QUERY_JSON_CACHE_MAX_SIZE) {
	const firstKey = buildSearchQueryJSONCache.keys().next().value;
	if (firstKey !== undefined) {
	buildSearchQueryJSONCache.delete(firstKey);
	}
	}
	const frozen = Object.freeze(result);
	buildSearchQueryJSONCache.set(cacheKey, frozen);
	return frozen;
	} catch (e) {
	console.error(`Error when parsing SearchQuery: "${query}"`, e);
	}
	}

After the parser produces result and before the object is frozen and cached, we will check whether result.groupBy is one of the values listed in CONST.SEARCH.GROUP_BY. If it is not, we will set result.groupBy to undefined. We will also clear result.view in the same branch when there is no longer a valid groupBy, because the rest of the code already treats view as meaningful only when a groupBy is set (for example buildSearchQueryString only emits view: in the URL when queryJSON?.groupBy is truthy, and buildFilterFormValuesFromQuery only writes the form view field when queryJSON.groupBy is set), so dropping view here keeps the cached object internally consistent.

We will also remove the corresponding groupBy (and, for consistency, view when it gets dropped) entries from result.rawFilterList if the parser stored them there as default raw filters. That list is what buildUserReadableQueryString walks to produce the human-readable query string shown in the search input, via formatDefaultRawFilterSegment:

App/src/libs/SearchQueryUtils.ts

Lines 1646 to 1704 in c300f98

	if (rawFilterList && rawFilterList.length > 0) {
	const segments: string[] = [];
	for (const rawFilter of rawFilterList) {
	if (!rawFilter) {
	continue;
	}
	if (rawFilter.isDefault) {
	const defaultSegment = formatDefaultRawFilterSegment(rawFilter, policies, reports);
	if (defaultSegment) {
	segments.push(defaultSegment);
	}
	continue;
	}
	const rawValues = Array.isArray(rawFilter.value) ? rawFilter.value : [rawFilter.value];
	const queryFilters = rawValues
	.map((val) => (val ?? '').toString())
	.filter((val) => val.length > 0)
	.map((val) => ({
	operator: rawFilter.operator,
	value: val,
	}));
	if (!queryFilters.length) {
	continue;
	}
	const displayQueryFilters = getDisplayQueryFiltersForKey(
	rawFilter.key,
	queryFilters,
	PersonalDetails,
	reports,
	taxRates,
	cardList,
	cardFeeds,
	policies,
	currentUserAccountID,
	translate,
	reportAttributes,
	feedKeysWithCards,
	);
	if (!displayQueryFilters.length) {
	continue;
	}
	const segment = buildFilterValuesString(getUserFriendlyKey(rawFilter.key as SearchFilterKey), displayQueryFilters).trim();
	if (segment) {
	segments.push(segment);
	}
	}
	if (segments.length > 0) {
	return segments.join(' ');
	}
	}

Without that cleanup the search input would still display group-by:reports even after we drop the field from the rest of the JSON, which would be confusing.

After this single normalization step, all downstream consumers — the Save search page, the Display popup, the Advanced Filters form, the URL builder, the hash computation in getQueryHashes, and so on — will see groupBy as either undefined or one of the recognized values, and the translate(search.filters.groupBy.${value}) calls become safe by construction. The rest of the user's filters (such as from) are kept intact because we are only touching the unrecognized root-level field, not the flat filter list.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/89168-search-groupby-validation?expand=1

Result

Kapture.2026-05-23.at.13.51.31.mp4

What alternative solutions did you explore? (Optional)

• Validate at every consumer that calls translate(search.filters.groupBy.${value}). This works but is more invasive (Save search page, Display popup, and any future consumer would need the same guard) and is easy to forget when adding new code paths, which is how this bug appeared in the first place.
• Make the Peggy grammar reject unknown groupBy literals during parse. This would mean group-by:reports causes the whole query to fail to parse, and the search page would show a generic parse error instead of recovering and showing the user's other filters. Silently dropping the unknown value preserves the rest of the user's intent, which matches how the code already handles other unknown inputs (for example getValidGroupBy returning undefined).
• Add a fallback string in translate() for missing keys instead of triggering Log.alert. That would mask this and other genuine missing-translation bugs across the app, so it is not appropriate for a search-specific issue.

[melvin-bot]

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