[Due for payment 2026-05-12] [$250] Reports - Categories are not saving in the saved search after you rename it

[izarutskaya]

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:
Reproducible in staging?: Needs Reproduction
Reproducible in production?: Needs Reproduction
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: @marianaabussamra
Slack conversation (hyperlinked to channel name): #expensify_bugs

Action Performed:

1. Reports page
2. Expand Filters
3. Select multiple categories
4. Save search
5. Click on the three dots next to that search
6. Rename
7. Reopen the search and check the categories
8. Only a few categories are checked (most of them have been automatically unchecked)

Expected Result:

The categories should remain checked if they rename the saved search

Actual Result:

If they check the categories in that saved search before renaming it, they are still all checked. The issue happens after they renamed it, where most of the categories are unchecked automatically

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

Please check OP for the details.

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022044885836320080410
• Upwork Job ID: 2044885836320080410
• Last Price Increase: 2026-04-30

[MelvinBot]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[MelvinBot]

Proposal

What is the root cause of that problem?

The SEARCH_SAVED_SEARCH_RENAME route does not URL-encode the q (query) parameter when constructing the navigation URL. At ROUTES.ts:313, the query string is interpolated directly:

`search/saved-search/rename?name=${name}&q=${jsonQuery}`

Compare with SEARCH_ROOT at ROUTES.ts:306, which correctly encodes the same type of parameter:

`search?q=${encodeURIComponent(query)}...`

When React Navigation parses the unencoded URL, the query-string library splits on & characters and strips # fragments. If any category name contains & (e.g., "Food & Beverages"), everything after that & is treated as a separate URL parameter — truncating the query and losing all subsequent filter values. Characters like #, %, and + in category names cause similar corruption. The truncated query is then saved to the backend via saveSearch(), making the data loss permanent.

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

Add encodeURIComponent to the q parameter in the SEARCH_SAVED_SEARCH_RENAME route, matching the pattern already used by SEARCH_ROOT:

In ROUTES.ts:313, change the getRoute to encode the jsonQuery parameter:

`search/saved-search/rename?name=${name}&q=${encodeURIComponent(jsonQuery)}`

React Navigation already calls decodeURIComponent when parsing route params, so SavedSearchRenamePage will receive the correct decoded value without any changes needed on the receiving end.

What alternative solutions did you explore? (Optional)

An alternative would be to pass the query via navigation state params instead of URL query params, but that would be inconsistent with how SEARCH_ROOT handles it and would require more invasive changes to the navigation setup.

Investigation details

Data flow of the bug:

1. User's saved search has a query like type:expense category:Food & Beverages,Travel,Office
2. User clicks rename → SearchUIUtils.ts:4132 navigates with inputQuery passed unencoded
3. URL becomes: search/saved-search/rename?name=...&q=type:expense category:Food & Beverages,Travel,Office
4. query-string parser splits on & → q becomes type:expense category:Food (truncated)
5. SavedSearchRenamePage.tsx receives the truncated q param
6. buildSearchQueryJSON() parses the truncated query → most categories are lost
7. saveSearch() persists the corrupted query to the backend, making the loss permanent

Note: The name param is correctly pre-encoded via encodeURIComponent(itemName) at the call site, but jsonQuery receives no encoding at all — confirming this is an oversight rather than an intentional design choice.

---

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 - @hungvu193 (External)

[melvin-bot]

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

[wildan-m]

Proposal

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

When a user creates a saved search filtering by multiple categories and then renames the saved search, reopening the search shows that most of the previously selected categories have become unchecked. The categories that survive the rename appear to be the first few; everything after a certain point is silently dropped.

What is the root cause of that problem?

The rename route at SEARCH_SAVED_SEARCH_RENAME builds the URL by interpolating the saved query string directly into the q= query parameter without URL-encoding it:

App/src/ROUTES.ts

Lines 311 to 314 in 858961f

	SEARCH_SAVED_SEARCH_RENAME: {
	route: 'search/saved-search/rename',
	getRoute: ({name, jsonQuery}: {name: string; jsonQuery: SearchQueryString}) => `search/saved-search/rename?name=${name}&q=${jsonQuery}` as const,
	},

The caller passes the stored inputQuery raw:

App/src/libs/SearchUIUtils.ts

Lines 4115 to 4138 in 858961f

	function getOverflowMenu(
	icons: OverflowMenuIconsType,
	itemName: string,
	hash: number,
	inputQuery: string,
	translate: LocalizedTranslate,
	showDeleteModal: (hash: number) => void,
	isMobileMenu?: boolean,
	closeMenu?: () => void,
	) {
	return [
	{
	text: translate('common.rename'),
	onSelected: () => {
	if (isMobileMenu && closeMenu) {
	closeMenu();
	}
	Navigation.navigate(ROUTES.SEARCH_SAVED_SEARCH_RENAME.getRoute({name: encodeURIComponent(itemName), jsonQuery: inputQuery}));
	},
	icon: icons.Pencil,
	shouldShowRightIcon: false,
	shouldShowRightComponent: false,
	shouldCallAfterModalHide: true,
	},

A typical saved search query containing multiple categories looks like type:expense category:Travel,"Office Supplies","Travel & Entertainment","Software". Once that string is interpolated unencoded into the URL, the unencoded & is parsed as a query-parameter delimiter. React Navigation reads route.params.q as only the substring up to the first & — so the value handed to SavedSearchRenamePage becomes type:expense category:Travel,"Office Supplies","Travel (truncated). Spaces, quotes, #, and + in category values have similar URL-decoding hazards.

SavedSearchRenamePage then rebuilds the JSON from this truncated string and saves it back to Onyx:

App/src/pages/Search/SavedSearchRenamePage.tsx

Lines 38 to 47 in 858961f

	const onSaveSearch = () => {
	const queryJSON = buildSearchQueryJSON(q || buildCannedSearchQuery()) ?? ({} as SearchQueryJSON);
	saveSearch({
	queryJSON,
	newName: newName?.trim() || q,
	});
	applyFiltersAndNavigate();
	};

saveSearch writes that truncated query string back into the saved search entry, so the user-visible categories after reopening reflect only the survivors that appeared before the first URL-special character:

App/src/libs/actions/Search.ts

Lines 362 to 402 in 858961f

	function saveSearch({queryJSON, newName}: {queryJSON: SearchQueryJSON; newName?: string}) {
	const saveSearchName = newName ?? queryJSON?.inputQuery ?? '';
	const jsonQuery = JSON.stringify(queryJSON);
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.SAVED_SEARCHES>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.SAVED_SEARCHES}`,
	value: {
	[queryJSON.hash]: {
	pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD,
	name: saveSearchName,
	query: queryJSON.inputQuery,
	},
	},
	},
	];
	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.SAVED_SEARCHES>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.SAVED_SEARCHES}`,
	value: {
	[queryJSON.hash]: null,
	},
	},
	];
	const successData: Array<OnyxUpdate<typeof ONYXKEYS.SAVED_SEARCHES>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.SAVED_SEARCHES}`,
	value: {
	[queryJSON.hash]: {
	pendingAction: null,
	},
	},
	},
	];
	API.write(WRITE_COMMANDS.SAVE_SEARCH, {jsonQuery, newName: saveSearchName}, {optimisticData, failureData, successData});
	}

This is why "most" categories become unchecked rather than "all" — categories whose serialized form sits before the truncation point survive, the rest are silently dropped. Standard accounting category names like "Travel & Entertainment" and "Meals & Entertainment" reliably trigger this on the very first rename.

The same file already encodes other query strings correctly. The SEARCH_ROOT route encodes its q and rawQuery parameters via encodeURIComponent:

App/src/ROUTES.ts

Lines 302 to 308 in 858961f

	SEARCH_ROOT: {
	route: 'search',
	getRoute: ({query, rawQuery, name}: {query: SearchQueryString; rawQuery?: SearchQueryString; name?: string}) => {
	const rawQuerySegment = rawQuery ? `&rawQuery=${encodeURIComponent(rawQuery)}` : '';
	return `search?q=${encodeURIComponent(query)}${name ? `&name=${name}` : ''}${rawQuerySegment}` as const;
	},
	},

The rename route is the one outlier that forgot to encode.

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

Wrap the jsonQuery interpolation in encodeURIComponent inside SEARCH_SAVED_SEARCH_RENAME.getRoute, mirroring how SEARCH_ROOT.getRoute already handles its query parameter on the line above. After the change, the rename URL becomes percent-encoded, React Navigation decodes route.params.q back to the original full query string, and SavedSearchRenamePage rebuilds the JSON from the complete filter set — so the rename writes the unchanged query back into Onyx and the categories remain checked when the search is reopened.

No other change is required: the rest of the rename flow already does the right thing once it receives an intact q. SavedSearchRenamePage's existing applyFiltersAndNavigate call to ROUTES.SEARCH_ROOT.getRoute({query: q, name: newName?.trim()}) still works correctly because SEARCH_ROOT.getRoute independently encodes its own query parameter.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/88152-encode-saved-search-rename-query?expand=1

What alternative solutions did you explore? (Optional)

Encoding at the call site in SearchUIUtils.ts:getOverflowMenu (wrapping inputQuery with encodeURIComponent before passing it to getRoute) was considered, but encoding inside the route definition matches the pattern already used by sibling routes in the same file (SEARCH_ROOT, SEARCH_HOLD, etc.) and keeps the encoding contract owned by the route, so future callers cannot reintroduce the same bug by forgetting to encode upstream.

[aimane-chnaif]

This is no longer reproducible on main/staging

[hungvu193]

Not able to reproduce on latest staging. @izarutskaya Can QA team reproduce this one?