[$250] Web - Spend - Order of the Coloumn is not remain after clear cache and restart

[applause-bot]

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.98-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-37769/folder/30823848/71826932/1459450647?sort=%2Bidentifier&status_id=1014144
Email or phone of affected tester (no customers): leungbratt6@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 10/Chrome
App Component: Left Hand Navigation (LHN)

Action Performed:

Precondition: The user has some report expenses in the Workspace chat

1. Navigate to Spend > Reports
2. Click on the Display > Edit Columns button
3. Move a couple of columns around > Save
4. Go to Troubleshoot > clear cache and restart
5. Go back to Spend > Reports
6. Verify the order of the columns remains the same

Expected Result:

8. Verify the order of the columns remains the same

Actual Result:

The order of the columns has been reset

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7170664_1780504348090.order.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7170664

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022062218181205714629
• Upwork Job ID: 2062218181205714629
• Last Price Increase: 2026-06-03

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/905ef5cc1db10fb9e8faa3bfd433fcbdea47eb0467b731b89575523b1ae52096

[MelvinBot]

Proposal

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

Custom column order set via Spend → Reports → Display → Edit Columns is lost after Troubleshoot → clear cache and restart. The expected behavior is that the saved order persists.

What is the root cause of that problem?

There is no persistence layer for the Search/Reports column order. The order lives only in the search query string (the URL), which does not survive a cache clear, and the "Reports" tab always rebuilds a fresh default query that has no column information.

1. Saving columns only writes them into a query string and navigates — it never calls API.write or stores an NVP: SearchColumnsPage.tsx:43-56.
2. "clear cache and restart" wipes Onyx, preserving only an allowlist (KEYS_TO_PRESERVE) that does not include any column data: App.ts:128-153.
3. The "Reports" tab builds its query with buildCannedSearchQuery({type: 'expense-report'}), which only emits type / status / group-by / policyID / expense-type — never a columns: clause — so it always renders the default order: SearchUIUtils.ts:726-731 and SearchQueryUtils.ts:1798-1828.

So the customization is inherently ephemeral. Note: the per-report transaction list (MoneyRequestReportView) does persist its columns via the nvp_reportDetailsColumns NVP (ReportLayout.ts:51-73) — but the Search results table has no equivalent.

Investigation details & alternatives considered

• Within-session vs. cache clear: Because the "Reports" tab query is rebuilt from buildCannedSearchQuery with no columns:, the order is actually only retained while you stay on the saved URL. The QA test surfaces the loss via the cache-clear step, but the underlying gap is the absence of any saved preference.
• Saved Searches (nvp_savedSearches) do persist a query string including columns:, but the canned "Reports" tab does not load a saved search, so that path doesn't help here.
• Why a local fix is insufficient: Adding the draft form key to KEYS_TO_PRESERVE would be the wrong fix — clearing cache is meant to wipe local data and re-fetch from the server, and a local-only value wouldn't sync across devices/sessions. A user preference like this belongs in a backend NVP.
• Confidence: High on the mechanism (fully evidenced in code). Whether persistence is a never-implemented feature vs. a true code regression is a product call — but the regression test's expected result confirms persistence is the intended behavior.

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

Persist the user's selected columns (per Search data type, e.g. expense-report) to a new backend NVP, mirroring the existing nvp_reportDetailsColumns pattern, then read that NVP when building the "Reports"/Search canned query so the saved order is re-applied. The App-side changes (set the NVP on save in applyChanges, read it in buildCannedSearchQuery/getSuggestedSearches) are straightforward, but they depend on the backend NVP existing first.

⚠️ This fix requires changes outside the Expensify/App repo. A new NVP must be created/allowlisted on the backend (a dedicated write command like SET_REPORT_DETAILS_COLUMNS, or allowlisting a new name for SET_NAME_VALUE_PAIR). MelvinBot can't implement the backend portion, so this needs an internal engineer to add the NVP before the App-side wiring lands.

---

Next Steps for Contributor+ team:
To proceed: This needs an internal engineer to create the backend NVP for Search column persistence; the App-side wiring can follow once that exists.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[aswin-s]

Proposal

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

On Web, after a user customizes the column order in Spend > Reports via Display > Edit Columns > Save, then performs Troubleshoot > Clear Cache and Restart, the saved column order is reset to the default instead of remaining as the user configured it. Expected: the previously saved column order should persist across cache clear/restart.

What is the root cause of that problem?

The user's column selection/order is persisted only as a columns: clause inside the Search URL query string (see SearchColumnsPage.applyChanges in src/pages/Search/SearchColumnsPage.tsx:43-56, which writes the columns into buildQueryStringFromFilterFormValues and replaces the route). There is no Onyx/NVP persistence of column ordering — searching src/ONYXKEYS.ts shows only NVP_SAVED_CSV_COLUMN_LAYOUT_LIST (for CSV exports), and getColumnsToShow in src/libs/SearchUIUtils.ts:5269 derives column order purely from the visibleColumns passed in from the parsed query. After "Clear Cache and Restart", the app reloads and the user re-enters Spend > Reports through the default sidebar route, which produces a query string without a columns: clause, so visibleColumns is empty and getColumnsToShow falls back to the default order at src/libs/SearchUIUtils.ts:5316/:5376.

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

1. Add a new NVP-backed Onyx key (e.g. NVP_SEARCH_COLUMNS_BY_TYPE) in src/ONYXKEYS.ts to store the user's last-applied column ordering, keyed by {type, groupBy} (so Expense, Expense Reports, and each Group By have independent saved orders).
2. In src/pages/Search/SearchColumnsPage.tsx applyChanges (lines 43–56), in addition to writing the columns to the URL query string, persist selectedColumnIds into the new NVP via a Search.saveColumnPreference({type, groupBy, columns}) action (add in src/libs/actions/Search.ts) so it survives reload.
3. In src/components/Search/index.tsx (around columnsToShow derivation near line 1378) or wherever visibleColumns is computed from the parsed query, fall back to the persisted NVP value for the current {type, groupBy} when the URL has no columns: clause, before defaulting to the built-in ordering.
4. Ensure the persistence is per-type/groupBy so switching data types doesn't cross-contaminate, mirroring the keying used in getColumnsToShow (src/libs/SearchUIUtils.ts:5269).
5. Send the NVP write to the backend (parameters file under src/libs/API/parameters/) so the preference also persists across devices, consistent with other NVP-backed UI preferences.

What alternative solutions did you explore? (Optional)

Restoring the last Search URL on app start instead of adding an NVP — rejected because clearing cache by design wipes session state, and other entry points (sidebar, deep link) would still land on a column-less URL.

[MobileMage]

Proposal

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

On Spend > Reports, the user opens Display > Edit Columns, drags columns into a custom order, taps Save, then runs Troubleshoot > Clear cache and restart. When they return to Spend > Reports the table reverts to the default column order. The customisation is gone for the rest of the session and every subsequent visit.

What is the root cause of that problem?

The column order from Edit Columns is never persisted server-side. It lives in two client-only places: the columns: segment of the q query string, and columns on the searchAdvancedFiltersForm Onyx form. SearchColumnsPage.applyChanges writes the saved order into the URL and nothing else:

App/src/pages/Search/SearchColumnsPage.tsx

Lines 43 to 56 in 8020a93

	const applyChanges = (selectedColumnIds: SearchCustomColumnIds[]) => {
	const updatedAdvancedFilters: Partial<SearchAdvancedFiltersForm> = {
	...searchAdvancedFiltersForm,
	columns: selectedColumnIds,
	};
	const currentQueryJSON = getCurrentSearchQueryJSON();
	const queryString = buildQueryStringFromFilterFormValues(updatedAdvancedFilters, {
	sortBy: currentQueryJSON?.sortBy,
	sortOrder: currentQueryJSON?.sortOrder,
	});
	Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute({query: queryString}), {forceReplace: true});
	};

The Search table reads the order from Onyx, not the URL directly:

App/src/components/Search/index.tsx

Line 310 in 8020a93

const [visibleColumns] = useOnyx(ONYXKEYS.FORMS.SEARCH_ADVANCED_FILTERS_FORM, {selector: columnsSelector});

The form is hydrated from the URL by useSearchFilterSync, which calls updateAdvancedFilters(formValues, true) → Onyx.set(SEARCH_ADVANCED_FILTERS_FORM, values), a hard overwrite of the whole form.

Troubleshoot > Clear cache and restart flows through clearOnyxAndResetApp → Onyx.clear(KEYS_TO_PRESERVE). The preserve list only carries session/account/locale/theme keys; ONYXKEYS.FORMS.SEARCH_ADVANCED_FILTERS_FORM is not in it, so the form is wiped:

App/src/libs/actions/App.ts

Lines 128 to 153 in 8020a93

	const KEYS_TO_PRESERVE: OnyxKey[] = [
	ONYXKEYS.ACCOUNT,
	ONYXKEYS.RAM_ONLY_IS_CHECKING_PUBLIC_ROOM,
	ONYXKEYS.IS_LOADING_APP,
	ONYXKEYS.RAM_ONLY_IS_SIDEBAR_LOADED,
	ONYXKEYS.MODAL,
	ONYXKEYS.NETWORK,
	ONYXKEYS.SESSION,
	ONYXKEYS.NVP_TRY_FOCUS_MODE,
	ONYXKEYS.PREFERRED_THEME,
	ONYXKEYS.NVP_PREFERRED_LOCALE,
	ONYXKEYS.CREDENTIALS,
	ONYXKEYS.PRESERVED_USER_SESSION,
	ONYXKEYS.PRESERVED_ACCOUNT,
	ONYXKEYS.HYBRID_APP,
	ONYXKEYS.SHOULD_USE_STAGING_SERVER,
	ONYXKEYS.IS_DEBUG_MODE_ENABLED,
	ONYXKEYS.COLLECTION.PASSKEY_CREDENTIALS,
	ONYXKEYS.COLLECTION.DEVICE_BIOMETRICS,
	ONYXKEYS.STASHED_SESSION,
	ONYXKEYS.STASHED_CREDENTIALS,
	// Preserve IS_USING_IMPORTED_STATE so that when the app restarts (especially in HybridApp mode),
	// we know if we're in imported state mode and should skip API calls that would cause infinite loading
	ONYXKEYS.IS_USING_IMPORTED_STATE,
	];

After the clear, the user re-enters Spend > Reports through the LHN. The Reports menu item ships a canned query via buildCannedSearchQuery({type: EXPENSE_REPORT}), which builds the string from type/status/groupBy/policyID/cardID and emits no columns: segment. useSearchFilterSync parses that canned URL, gets a form value with columns === undefined, and on the first navigation in a fresh session overwrites Onyx via Onyx.set. visibleColumns becomes empty and getColumnsToShow falls back to defaultReportColumns.

Confirmed at runtime by instrumenting the four touch points (SearchColumnsPage.applyChanges, useSearchFilterSync, clearOnyxAndResetApp, and the visibleColumns useOnyx in Search/index.tsx):

1. Canned LHN navigation lands on /search with querySig type:expense-report sortBy:date sortOrder:desc. useSearchFilterSync calls Onyx.set with valuesColumns: undefined. visibleColumns: undefined. Table renders defaults.
2. After Save with 8 reordered columns, the URL changes to one containing columns:total,avatar,date,status,title,from,to,action. useSearchFilterSync calls Onyx.set with valuesColumns: [...8 items]. visibleColumns becomes Array(8). Table renders the saved order.
3. Clear cache and restart invokes clearOnyxAndResetApp, the Onyx.clear completes, and visibleColumns immediately drops from Array(8) to undefined. The form is gone.
4. Returning via the LHN, visibleColumns stays undefined. The table renders defaults again, reproducing the bug.

There is no durable backing store. The cache clear is enough on its own to lose the customisation; on a fresh session (new tab, post-logout, hard refresh) the LHN canned-query path would also Onyx.set over any preserved client-side value, because the URL it produces has no columns: segment.

The exact same ColumnsSettingsList component, when used for the per-report-details table, already has durable persistence wired up. ReportDetailsColumnsPage reads the saved order from NVP_REPORT_DETAILS_COLUMNS on mount and writes it back through setReportDetailsColumns, a textbook optimistic API.write with failure rollback:

App/src/libs/actions/ReportLayout.ts

Lines 49 to 73 in 8020a93

	* Set the user's report details columns preference
	*/
	function setReportDetailsColumns(columns: SearchCustomColumnIds[], previousValue?: string[] | null) {
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.NVP_REPORT_DETAILS_COLUMNS>> = [
	{
	onyxMethod: Onyx.METHOD.SET,
	key: ONYXKEYS.NVP_REPORT_DETAILS_COLUMNS,
	value: columns,
	},
	];
	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.NVP_REPORT_DETAILS_COLUMNS>> = [
	{
	onyxMethod: Onyx.METHOD.SET,
	key: ONYXKEYS.NVP_REPORT_DETAILS_COLUMNS,
	value: previousValue ?? null,
	},
	];
	const parameters = {
	columns: JSON.stringify(columns),
	};
	API.write(WRITE_COMMANDS.SET_REPORT_DETAILS_COLUMNS, parameters, {optimisticData, failureData});
	}

The Spend search columns page was never given the equivalent. That gap is the bug.

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

Mirror the report-details precedent: persist the Search column order to a server NVP, keyed so each table layout is remembered independently.

Add NVP_SEARCH_COLUMNS_BY_LAYOUT to ONYXKEYS storing a Record<string, SearchCustomColumnIds[]> map, keyed by ${type}:${groupBy ?? 'none'}. The map shape is needed because the user can configure a different layout per data type and per group-by (Expenses, Reports, grouped by category, grouped by member, and so on), and the column set itself differs per layout. A [type]-only key would collide across group-by variants of the same type and overwrite them.

Add a SET_SEARCH_COLUMNS write command and a setSearchColumns(layoutKey, columns, previousColumns) helper in ReportLayout.ts (or a dedicated SearchLayout.ts). The helper issues API.write(SET_SEARCH_COLUMNS, {layoutKey, columns: JSON.stringify(columns)}, {optimisticData, failureData}), modeled on setReportDetailsColumns.

In SearchColumnsPage.applyChanges, call the new helper before the existing Navigation.navigate(...). The URL update stays so the active session and any deep links keep working unchanged.

In Search/index.tsx, when searchAdvancedFiltersForm.columns is empty or undefined, fall back to NVP_SEARCH_COLUMNS_BY_LAYOUT[layoutKey] for the current ${type}:${groupBy}. The existing getColumnsToShow already treats an empty list as "use defaults", so the new path only narrows that case: NVP first, then defaults. The read-site fallback parallels the existing visibleColumns useOnyx and keeps Onyx I/O out of the pure query utilities in SearchQueryUtils.

Because the NVP is server-backed, this restores the layout on other devices and survives sign-out, matching NVP_REPORT_DETAILS_COLUMNS and NVP_REPORT_LAYOUT_GROUP_BY. The required TOTAL/TOTAL_AMOUNT/group-by columns stay enforced downstream by getColumnsToShow, so a stored partial list cannot break the table layout.

What alternative solutions did you explore? (Optional)

• Client-only patch: add ONYXKEYS.FORMS.SEARCH_ADVANCED_FILTERS_FORM to KEYS_TO_PRESERVE in App.ts. Rejected: it survives the in-process clear, but the form is also wiped by any LHN canned-query navigation that produces a different querySig than lastSyncedQuerySig. useSearchFilterSync then runs Onyx.set with no columns and the preserved value is gone. In the same-session repro the dedupe happens to short-circuit because the post-save signature with columns: is still in the module variable, but on any fresh module load (new tab, hard refresh, post-logout) the dedupe is empty and the overwrite fires. Only server-NVP persistence is durable across all of these.

• Restore the last Search URL on app start. Rejected: clearing cache by design wipes session state, and other entry points (LHN tap, deep link, expense-create redirect) bypass that restore and still land on a column-less URL.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-03 17:04:02 UTC.

Proposal

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

On Spend > Reports, after a user reorders columns via Display > Edit Columns > Save, the custom column order is lost once they Troubleshoot > clear cache and restart and navigate back to the search. The order resets to the defaults instead of being remembered.

What is the root cause of that problem?

The Search column customization is never persisted to a durable store — it only lives inside the navigation route's q query param.

When the user saves a new column order, SearchColumnsPage.applyChanges just rebuilds the query string and navigates; it does not write the preference anywhere durable:

https://github.com/Expensify/App/blob/2d8b35ed632/src/pages/Search/SearchColumnsPage.tsx#L43-L56

So the only thing holding the custom order is the in-memory SEARCH_ROOT route param (q). "Clear cache and restart" wipes Onyx and resets the navigation state, and when the user taps Spend again, SearchTabButton.navigateToSearch has no in-memory lastSearchRoute and no REPORT_NAVIGATION_LAST_SEARCH_QUERY (that Onyx key was cleared and isn't in KEYS_TO_PRESERVE), so it falls back to a canned query:

https://github.com/Expensify/App/blob/2d8b35ed632/src/components/Navigation/NavigationTabBar/SearchTabButton.tsx#L65-L68

buildCannedSearchQuery builds the query purely from type/status/groupBy/policyID — it carries no columns: customization, so the column segment it produces is always the default order:

https://github.com/Expensify/App/blob/2d8b35ed632/src/libs/SearchQueryUtils.ts#L1798-L1828

Hence the reset. Note REPORT_NAVIGATION_LAST_SEARCH_QUERY is only written when the user opens a report from the list, not on a column reorder, so even before the cache clear that key wouldn't carry the new order — the customization genuinely has nowhere durable to live.

Strong precedent that this is the gap: the exact same ColumnsSettingsList component, when used for the report-details table (ReportDetailsColumnsPage), already persists its column order to a backend NVP and reads it straight back on mount — which is why that table survives a cache clear:

• write: setReportDetailsColumns → SetReportDetailsColumns / nvp_reportDetailsColumns
• read: ReportDetailsColumnsPage reads the NVP into currentColumns

The Search columns page was simply never given the same durable persistence — it stops at the URL.

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

Mirror the report-details precedent: persist the Search column order per data type to an NVP and inject it back when a canned/default query is built.

1. New action + NVP, modeled exactly on setReportDetailsColumns — store a { [type]: SearchCustomColumnIds[] } map (so expense and expense-report keep independent orders) in a new nvp_searchColumns key via a new SetSearchColumns write command (the backend twin of the existing SetReportDetailsColumns).

2. Persist on save in SearchColumnsPage.applyChanges:

 const applyChanges = (selectedColumnIds: SearchCustomColumnIds[]) => {
+    // Durably persist the user's column preference for this data type so it survives
+    // navigation and clear-cache/restart, matching ReportDetailsColumnsPage behavior.
+    setSearchColumns(queryType, selectedColumnIds);
     const updatedAdvancedFilters: Partial<SearchAdvancedFiltersForm> = {
         ...searchAdvancedFiltersForm,
         columns: selectedColumnIds,
     };

3. Read it back when building the canned query so a fresh navigation restores the saved order instead of the default. In buildCannedSearchQuery, when no explicit columns are supplied, seed them from the saved NVP for that type (read via an Onyx.connect cache in SearchQueryUtils, the same way other utils there cache Onyx values):

-    // Parse the query to fill all default query fields with values
-    const normalizedQueryJSON = buildSearchQueryJSON(queryString);
+    // Parse the query to fill all default query fields with values
+    const normalizedQueryJSON = buildSearchQueryJSON(queryString);
+    // Restore the user's saved column order for this type, if any
+    const savedColumns = savedSearchColumnsByType?.[type];
+    if (savedColumns?.length && normalizedQueryJSON) {
+        normalizedQueryJSON.columns = savedColumns;
+    }
     return buildSearchQueryString(normalizedQueryJSON);

This fixes it everywhere a canned query is produced (the Spend tab fallback, "Reports", expense-create redirects), is offline-safe (optimistic Onyx update with failureData rollback, exactly like setReportDetailsColumns), syncs across devices, and matches the column-resolution already done in getColumnsToShow. The required TOTAL/TOTAL_AMOUNT columns continue to be enforced downstream by getColumnsToShow, so a stored partial list stays safe.

Affected platform is all of them (web/desktop where Edit Columns is available — shouldShowColumnsButton is gated to large screens); the change is platform-agnostic.

What alternative solutions did you explore? (Optional)

• Just add REPORT_NAVIGATION_LAST_SEARCH_QUERY to KEYS_TO_PRESERVE (App.ts#L128-L153) — rejected: that key is only written when opening a report, so in this repro (reorder, no report opened) it never holds the new order, and preserving stale search state across an explicit cache clear is the wrong semantic.
• Frontend-only: store the per-type column map in a dedicated Onyx key added to KEYS_TO_PRESERVE instead of a backend NVP — lighter (no backend command) and would survive clear cache, but it wouldn't sync across devices and diverges from the nvp_reportDetailsColumns pattern the team just established for the same component. I'd lead with the NVP for consistency, but this is a viable fallback if a backend command isn't desired.

[moxw]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

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

[melvin-bot]

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