[$250] Issue with Edit Columns in offline mode

[IuliiaHerets]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: v9.4.6-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/folder/30823848/test-cases/72255457?q=Offline+Modification+and+Exported+Column+Behavior

Action Performed:

1. Navigate to Spend > Reports and enable the Exported column via the Edit column selector
2. Verify Exported column dispalyed
3. Click Edit Columns, disable the Exported column, and click Save
4. Verify the "Exported" column cells not displayed in the table
5. Enter a search term in the report search bar to filter reports
6. Disconnect the device from the internet (Go offline)
7. Click on the "Columns" button again
8. Re-check/Enable the "Exported" column checkbox

Expected Result:

Exported column should be added to the table

Actual Result:

Page goes blank with an error message You appear to be offline

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

606381218-86d37aae-cc97-42ed-a49a-5d07ae1e5e1c.mov

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022065388064058618518
• Upwork Job ID: 2065388064058618518
• Last Price Increase: 2026-06-26

[MelvinBot]

Proposal

What is the root cause of that problem?

Toggling a column in the Reports table is treated as a brand-new search instead of a display-only change. When offline, that new search has no cached data, so the page renders the full-page "You appear to be offline" view instead of just showing/hiding the column.

Step by step:

1. Saving columns calls applyChanges(), which rebuilds the query string from the selected column IDs and navigates to a new SEARCH_ROOT route — SearchColumnsPage.tsx:43-56.
2. The list of columns is folded into the string that produces primaryHash — SearchQueryUtils.ts:533 then SearchQueryUtils.ts:538. That hash is the key for the Onyx snapshot, so a different column set = a different snapshot key.
3. Re-enabling "Exported" yields a hash whose snapshot was never fetched, so currentSearchResults is undefined.
4. While offline, the fetch that would populate the snapshot is skipped — Search/index.tsx:743-779 — and every loading/skeleton fallback is gated on !isOffline (useSearchLoadingState.ts:20-22).
5. So the render falls through to the searchResults === undefined branch, which returns <FullPageOfflineBlockingView> — Search/index.tsx:1776-1780. Offline, that renders the "You appear to be offline" message over the whole table.

The "Exported" column adds no new filter or data requirement — it only maps to a display column / sort key (SearchUIUtils.ts:308). The data needed to render it is already in the cached snapshot, so re-fetching is unnecessary in the first place.

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

Column visibility is a display concern, so changing it should not force a new uncached search. Either:

• Preferred — exclude the display-only columns segment from primaryHash (the snapshot lookup key) in getQueryHashes, so toggling columns reuses the existing snapshot and never blanks the page. Verify client-side sorting (e.g. sort-by-exported) still works, since it operates over the already-fetched snapshot data.

• Fallback (defense in depth) — at Search/index.tsx:1776, when offline and the snapshot is undefined, fall back to an empty state or the previously-cached results rather than the full-page offline block.

What alternative solutions did you explore? (Optional)

Persisting the resolved column set so a re-enable reproduces the exact previously-cached hash — but that's fragile (any column ordering/set the user hasn't visited online still blanks offline). Decoupling display columns from the snapshot hash addresses the root cause for all column combinations.

Confidence & verification notes

High confidence. Two independent investigations converged on the same single-branch render path; every alternative path that could prevent the blank page is independently gated on !isOffline. This is purely client-side render logic — reproducible offline locally, no production logs needed. Reproduced in staging and production per the report (v9.4.6-0, Web/Chrome).

Related issues

• [$250] Spend/Export - Default CSV option doesn't display when select report from 2 workspaces #93411 — also in Spend/Export, but a different symptom (default CSV option). Likely unrelated; noted only for awareness.

---

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

[KJ21-ENG]

Proposal

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

In Spend > Reports, after filtering the report list and going offline, re-enabling the Exported column from Edit Columns blanks the page and shows the offline blocker instead of showing the same loaded reports with the Exported column added.

What is the root cause of that problem?

SearchColumnsPage saves column changes by rebuilding the whole search query from SEARCH_ADVANCED_FILTERS_FORM, adding the selected columns, and force-replacing the Search route.

App/src/pages/Search/SearchColumnsPage.tsx

Lines 43 to 55 in 72c2763

	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});

That route change creates a different primary search hash because getQueryHashes() includes columns when building the primary hash.

App/src/libs/SearchQueryUtils.ts

Lines 531 to 538 in 72c2763

	orderedQuery += ` ${CONST.SEARCH.SYNTAX_ROOT_KEYS.SORT_BY}:${query.sortBy}`;
	orderedQuery += ` ${CONST.SEARCH.SYNTAX_ROOT_KEYS.SORT_ORDER}:${query.sortOrder}`;
	orderedQuery += ` ${CONST.SEARCH.SYNTAX_ROOT_KEYS.COLUMNS}:${Array.isArray(query.columns) ? query.columns.join(',') : query.columns}`;
	if (query.limit !== undefined) {
	orderedQuery += ` ${CONST.SEARCH.SYNTAX_ROOT_KEYS.LIMIT}:${query.limit}`;
	}
	const primaryHash = hashText(orderedQuery, 2 ** 32);

The old snapshot still contains the filtered report data, but SearchResultsProvider now reads SNAPSHOT<newHash>.

App/src/components/Search/SearchResultsProvider.tsx

Lines 40 to 63 in 72c2763

	const [snapshotSearchResults] = useOnyx(`${ONYXKEYS.COLLECTION.SNAPSHOT}${currentSearchHash}`);
	const shouldUseLiveData = !!currentSearchKey && isTodoSearch(currentRecentSearchHash, suggestedSearches);
	// If viewing a to-do search, use live data from useTodos, otherwise return the snapshot data
	// We do this so that we can show the counters for the to-do search results without visiting the specific to-do page, e.g. show `Approve [3]` while viewing the `Submit` to-do search.
	let currentSearchResults;
	if (shouldUseLiveData) {
	const liveData = todoSearchResultsData[currentSearchKey as keyof typeof todoSearchResultsData];
	const searchInfo: SearchResultsInfo = {
	...(snapshotSearchResults?.search ?? defaultSearchInfo),
	count: liveData.metadata.count,
	total: liveData.metadata.total,
	currency: liveData.metadata.currency,
	};
	const hasResults = Object.keys(liveData.data).length > 0;
	// For to-do searches, always return a valid SearchResults object (even with empty data)
	// This ensures we show the empty state instead of loading/blocking views
	currentSearchResults = {
	search: {...searchInfo, isLoading: false, hasResults},
	data: liveData.data,
	};
	} else {
	currentSearchResults = snapshotSearchResults ?? undefined;

While offline, useSearchPageSetup intentionally returns before calling search() for that new hash.

App/src/hooks/useSearchPageSetup.ts

Lines 56 to 58 in 72c2763

	useEffect(() => {
	if (!queryJSON || hash === undefined || shouldUseLiveData || isOffline) {
	return;

Because no destination snapshot exists, Search receives undefined results and renders FullPageOfflineBlockingView.

App/src/components/Search/index.tsx

Lines 1776 to 1779 in 72c2763

	if (searchResults === undefined) {
	Log.alert('[Search] Undefined search type');
	cancelNavigationSpans();
	return <FullPageOfflineBlockingView>{null}</FullPageOfflineBlockingView>;

This is wrong for a column-only update: the report set did not change, only the visible table columns did.

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

Keep the existing query/hash model, but make the column-save path reuse the already-loaded snapshot when the app is offline and the destination query differs only by columns.

In SearchColumnsPage:

• Read isOffline from useNetwork().
• Read currentSearchQueryJSON and currentSearchResults from the Search contexts instead of relying only on the preserved navigation helper.
• After building the updated query string, parse it with buildSearchQueryJSON().
• Before navigating, check all of these conditions:
  • app is offline;
  • both current and updated query JSON exist;
  • the current snapshot is loaded for the current query, e.g. isSearchDataLoaded(currentSearchResults, currentSearchQueryJSON) and currentSearchResults.data exists;
  • the current and updated queries are equivalent after normalizing/removing columns.
• When those conditions pass, copy the current snapshot into ${ONYXKEYS.COLLECTION.SNAPSHOT}${updatedQueryJSON.hash} with Onyx.set() or an equivalent exact replacement before calling Navigation.navigate().

That gives the new column-specific hash immediate data to render, so the table can recompute columnsToShow from the updated SEARCH_ADVANCED_FILTERS_FORM and display the Exported cells offline. The guard is important: this should not copy data for real query changes such as keyword, status, type, workspace, groupBy, sort, or pagination changes.

I would not remove columns from the primary hash or weaken the offline guard in useSearchPageSetup. Those changes are broader than the bug: the hash is used as Search state identity, and non-column query changes really do need fresh backend results when online.

Add regression coverage for:

• a loaded Reports search snapshot, offline network state, and a columns-only save populating the destination snapshot and navigating to the updated route;
• online column changes continuing to navigate without pre-seeding snapshots;
• offline changes that alter anything other than columns not copying stale data.

What alternative solutions did you explore? (Optional)

Using recentSearchHash/similarSearchHash or removing columns from primaryHash would also avoid the missing snapshot in this one flow, but those options can collapse distinct Search UI states. Letting search() run offline would bypass an intentional network guard and still cannot produce new data. The scoped snapshot copy matches the actual data dependency: columns are presentation-only for an already-loaded result set.

[mukhrr]

Proposal

What is the root cause of that problem?

Changing columns is treated as a new search query, even though it only changes presentation.

In SearchColumnsPage, saving the column selector rebuilds the search query with the selected columns and navigates to /search with forceReplace:

App/src/pages/Search/SearchColumnsPage.tsx

Lines 43 to 55 in dd5a318

	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});

columns is included in the primary search hash:

App/src/libs/SearchQueryUtils.ts

Lines 531 to 538 in dd5a318

	orderedQuery += ` ${CONST.SEARCH.SYNTAX_ROOT_KEYS.SORT_BY}:${query.sortBy}`;
	orderedQuery += ` ${CONST.SEARCH.SYNTAX_ROOT_KEYS.SORT_ORDER}:${query.sortOrder}`;
	orderedQuery += ` ${CONST.SEARCH.SYNTAX_ROOT_KEYS.COLUMNS}:${Array.isArray(query.columns) ? query.columns.join(',') : query.columns}`;
	if (query.limit !== undefined) {
	orderedQuery += ` ${CONST.SEARCH.SYNTAX_ROOT_KEYS.LIMIT}:${query.limit}`;
	}
	const primaryHash = hashText(orderedQuery, 2 ** 32);

So when the user enables exported, we switch from the old snapshot_{oldHash} to a new snapshot_{newHash}. Search results are read strictly by that current hash:

App/src/components/Search/SearchResultsProvider.tsx

Lines 35 to 64 in dd5a318

	function SearchResultsProvider({children}: SearchResultsProviderProps) {
	const {currentSearchHash, currentSearchKey, currentSearchQueryJSON, suggestedSearches} = useSearchQueryContext();
	const currentRecentSearchHash = currentSearchQueryJSON?.recentSearchHash ?? -1;
	const todoSearchResultsData = useTodos();
	const [snapshotSearchResults] = useOnyx(`${ONYXKEYS.COLLECTION.SNAPSHOT}${currentSearchHash}`);
	const shouldUseLiveData = !!currentSearchKey && isTodoSearch(currentRecentSearchHash, suggestedSearches);
	// If viewing a to-do search, use live data from useTodos, otherwise return the snapshot data
	// We do this so that we can show the counters for the to-do search results without visiting the specific to-do page, e.g. show `Approve [3]` while viewing the `Submit` to-do search.
	let currentSearchResults;
	if (shouldUseLiveData) {
	const liveData = todoSearchResultsData[currentSearchKey as keyof typeof todoSearchResultsData];
	const searchInfo: SearchResultsInfo = {
	...(snapshotSearchResults?.search ?? defaultSearchInfo),
	count: liveData.metadata.count,
	total: liveData.metadata.total,
	currency: liveData.metadata.currency,
	};
	const hasResults = Object.keys(liveData.data).length > 0;
	// For to-do searches, always return a valid SearchResults object (even with empty data)
	// This ensures we show the empty state instead of loading/blocking views
	currentSearchResults = {
	search: {...searchInfo, isLoading: false, hasResults},
	data: liveData.data,
	};
	} else {
	currentSearchResults = snapshotSearchResults ?? undefined;
	}

This is fine online because useSearchPageSetup fetches the missing snapshot. But offline it intentionally skips search():

App/src/hooks/useSearchPageSetup.ts

Lines 56 to 73 in dd5a318

	useEffect(() => {
	if (!queryJSON || hash === undefined || shouldUseLiveData || isOffline) {
	return;
	}
	// Must run even on cached snapshots, else SearchTabButton's Onyx fallback restores
	// a stale query after a tab switch (e.g. filter reappears after Reset).
	if (lastSavedSearchHash !== hash) {
	saveLastSearchParams({queryJSON, offset: 0, searchKey: currentSearchKey, hasMoreResults: false, allowPostSearchRecount: false});
	lastSavedSearchHash = hash;
	}
	if (isSnapshotDataLoaded || isSnapshotSearchLoading) {
	return;
	}
	const shouldSkipWaitForWrites = hasDeferredWrite(CONST.DEFERRED_LAYOUT_WRITE_KEYS.SEARCH);
	search({queryJSON, searchKey: currentSearchKey, offset: 0, shouldCalculateTotals, isLoading: false, skipWaitForWrites: shouldSkipWaitForWrites});
	}, [hash, isOffline, shouldUseLiveData, queryJSON, isSnapshotDataLoaded, isSnapshotSearchLoading, currentSearchKey, shouldCalculateTotals]);

Therefore the new hash has no snapshot. Since Search receives searchResults === undefined, it renders the blocking offline view instead of continuing to render the already-loaded table:

App/src/components/Search/index.tsx

Lines 1789 to 1792 in dd5a318

	isBreakLine: shouldUseNarrowLayout,
	})}
	subtitle={translate(isInvalidQuery ? 'errorPage.wrongTypeSubtitle' : 'errorPage.subtitle')}
	/>

This is the same class of issue fixed in #88960 / PR #89081: when Search is offline, it cannot rely on fetching a missing snapshot_{hash} and must preserve or create usable local snapshot data. PR #89081 fixed that for offline-created expenses by restoring optimistic snapshot updates:
#89081

This issue is exposed now by column-only hash changes. PR #91501 recently added export-related columns to the Search table, including exported / exportedto, which makes this path easier to hit:
#91501

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

Keep using the last loaded snapshot while offline when the only query difference is columns.

This should be done in SearchPage, before passing searchResults into SearchPageWide/SearchPageNarrow. We already store lastNonEmptySearchResults; we should also store the query JSON that produced it. If the current hash has no snapshot, the app is offline, and the previous/current queries are identical except for columns, pass the last snapshot as the fallback.

Small illustrative diff:

diff --git a/src/pages/Search/SearchPage.tsx b/src/pages/Search/SearchPage.tsx
@@
 import type {SearchParams} from '@components/Search/types';
+import type {SearchQueryJSON} from '@components/Search/types';
@@
 function SearchPage({route}: SearchPageProps) {
@@
     const [lastNonEmptySearchResults, setLastNonEmptySearchResults] = useState<SearchResults | undefined>(undefined);
+    const [lastNonEmptySearchQueryJSON, setLastNonEmptySearchQueryJSON] = useState<Readonly<SearchQueryJSON> | undefined>(undefined);
@@
     if (currentSearchResults?.data && !shouldUseLiveData && currentSearchResults !== lastNonEmptySearchResults) {
         setLastNonEmptySearchResults(currentSearchResults);
+        setLastNonEmptySearchQueryJSON(currentSearchQueryJSON);
     }
@@
-    if (currentSearchResults?.data != null || currentSearchResults?.errors) {
+    const shouldUseOfflineColumnFallback =
+        isOffline &&
+        !currentSearchResults &&
+        lastNonEmptySearchResults?.data &&
+        areSearchQueriesEqualExceptColumns(lastNonEmptySearchQueryJSON, currentSearchQueryJSON);
+
+    if (currentSearchResults?.data != null || currentSearchResults?.errors) {
         searchResults = currentSearchResults;
+    } else if (shouldUseOfflineColumnFallback) {
+        searchResults = lastNonEmptySearchResults;
     } else if (isSorting) {
         searchResults = lastNonEmptySearchResults;
     }

The comparison helper should ignore only columns, not filters/sort/type/status/grouping:

function areSearchQueriesEqualExceptColumns(previous?: Readonly<SearchQueryJSON>, current?: Readonly<SearchQueryJSON>) {
    if (!previous || !current) {
        return false;
    }

    const {columns: previousColumns, hash: previousHash, ...previousComparable} = previous;
    const {columns: currentColumns, hash: currentHash, ...currentComparable} = current;

    return JSON.stringify(previousComparable) === JSON.stringify(currentComparable);
}

To avoid regressions:

• Only use the fallback while isOffline.
• Only use it when the new hash has no snapshot.
• Ignore only columns; do not fallback for status/filter/type/group/sort changes.
• Do not write copied data into snapshot_{newHash}; just render the fallback snapshot until online refresh creates the real snapshot.
• Keep existing online behavior unchanged, so server-backed search results still refresh normally.

What alternative solutions did you explore? (Optional)

We could remove columns from the search hash, but that is risky because saved/recent searches and URL identity currently include display settings.

We could copy snapshot_{oldHash} into snapshot_{newHash} inside SearchColumnsPage, but that spreads Search snapshot ownership into the column selector and can create stale cached snapshots.

We could disable column changes offline, but column visibility is a local display preference and the existing loaded data is enough to render the newly selected column.

Demo of main solution:

demo.mp4

[Abdukhamid000]

Proposal

What is the root cause of that problem?

columns is folded into the primary search hash by [getQueryHashes](https://github.com/Expensify/App/blob/main/src/libs/SearchQueryUtils.ts#L478-L536):

https://github.com/Expensify/App/blob/main/src/libs/SearchQueryUtils.ts#L529-L536

So when the user saves the columns picker, [SearchColumnsPage.applyChanges](https://github.com/Expensify/App/blob/main/src/pages/Search/SearchColumnsPage.tsx#L43-L56) builds a new query string and navigates to it, producing a brand-new currentSearchHash. The search context reads useOnyx(${SNAPSHOT}${currentSearchHash}) in [SearchContext.tsx](https://github.com/Expensify/App/blob/main/src/components/Search/SearchContext.tsx#L116) and there's no snapshot stored for the new hash yet, so currentSearchResults is undefined.

In [Search/index.tsx](https://github.com/Expensify/App/blob/main/src/components/Search/index.tsx#L1665-L1668), searchResults === undefined short-circuits to:

if (searchResults === undefined) {
    Log.alert('[Search] Undefined search type');
    cancelNavigationSpans();
    return <FullPageOfflineBlockingView>{null}</FullPageOfflineBlockingView>;
}

Online, a fresh search request fires for the new hash and the snapshot lands a moment later, so the user barely notices. Offline, that request can't run, so the snapshot stays undefined and the user sees the "You appear to be offline" blocking view permanently.

The hash includes columns even though columns are a presentation-only concern — the server response is identical regardless of which columns the client renders. similarSearchHash and recentSearchHash are computed before the columns line, so they already exclude it. Only the primary hash (the one driving snapshot lookup) is sensitive to it.

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

Stop including columns in the primary hash so toggling a column reuses the existing snapshot instead of forcing a new fetch:

     orderedQuery += ` ${CONST.SEARCH.SYNTAX_ROOT_KEYS.SORT_BY}:${query.sortBy}`;
     orderedQuery += ` ${CONST.SEARCH.SYNTAX_ROOT_KEYS.SORT_ORDER}:${query.sortOrder}`;
-    orderedQuery += ` ${CONST.SEARCH.SYNTAX_ROOT_KEYS.COLUMNS}:${Array.isArray(query.columns) ? query.columns.join(',') : query.columns}`;

     if (query.limit !== undefined) {
         orderedQuery += ` ${CONST.SEARCH.SYNTAX_ROOT_KEYS.LIMIT}:${query.limit}`;
     }
     const primaryHash = hashText(orderedQuery, 2 ** 32);

The column selection still persists through the URL query string and SEARCH_ADVANCED_FILTERS_FORM, so the table re-renders with the new columns. The snapshot data is keyed by the unchanged hash, so currentSearchResults stays defined, the blocking view doesn't trigger, and offline the user just sees the column re-appear with the data they already had.

I'd also harden the empty branch in Search/index.tsx so it doesn't fall through to FullPageOfflineBlockingView purely because the snapshot for a hash is missing — if isOffline is true and there's no snapshot yet, render the skeleton or last-known data instead of the offline blocker. That keeps the UX sane if a similar hash-change path slips in later.

What alternative solutions did you explore?

• Keep the hash sensitive to columns and copy the snapshot under the new hash key when columns change. Doubles storage for the same data and adds bookkeeping at every save. Cheaper to just stop changing the hash.
• In SearchColumnsPage.applyChanges, write the columns directly into the form without navigating. Would work but breaks deep linking and back-button restore of the previous column state, since the URL query is the source of truth.

[melvin-bot]

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

[melvin-bot]

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

[lorretheboy]

Proposal

What is the root cause of that problem?

Toggling a column rebuilds the search query and navigates to a brand‑new search whose snapshot has never been loaded; offline, that snapshot can never be fetched, so Search falls back to the full‑page offline blocking view.

Saving the column selection rebuilds the query string and force‑replaces the route here:

App/src/pages/Search/SearchColumnsPage.tsx

Lines 43 to 56 in 72c2763

	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 problem is that the visible columns are folded into the search's primaryHash, which becomes queryJSON.hash:

App/src/libs/SearchQueryUtils.ts

Lines 531 to 540 in 72c2763

	orderedQuery += ` ${CONST.SEARCH.SYNTAX_ROOT_KEYS.SORT_BY}:${query.sortBy}`;
	orderedQuery += ` ${CONST.SEARCH.SYNTAX_ROOT_KEYS.SORT_ORDER}:${query.sortOrder}`;
	orderedQuery += ` ${CONST.SEARCH.SYNTAX_ROOT_KEYS.COLUMNS}:${Array.isArray(query.columns) ? query.columns.join(',') : query.columns}`;
	if (query.limit !== undefined) {
	orderedQuery += ` ${CONST.SEARCH.SYNTAX_ROOT_KEYS.LIMIT}:${query.limit}`;
	}
	const primaryHash = hashText(orderedQuery, 2 ** 32);
	return {primaryHash, recentSearchHash, similarSearchHash};

That hash is the Onyx snapshot key (SNAPSHOT}${hash}), so a different column set points at a different, never‑populated snapshot. Online this is invisible because the missing snapshot just triggers a Search API call. Offline, that fetch is skipped early:

App/src/components/Search/index.tsx

Lines 747 to 750 in 72c2763

	const comingBackOnlineWithNoResults = prevIsOffline && !isOffline && isEmptyObject(searchResults?.data);
	if (!comingBackOnlineWithNoResults && ((!isFocused && !isMigratedModalDisplayed) || isOffline)) {
	return;
	}

so searchResults stays undefined and the component renders the blank "You appear to be offline" page:

App/src/components/Search/index.tsx

Lines 1776 to 1779 in 72c2763

	if (searchResults === undefined) {
	Log.alert('[Search] Undefined search type');
	cancelNavigationSpans();
	return <FullPageOfflineBlockingView>{null}</FullPageOfflineBlockingView>;

Causal chain: enable column → query string changes → columns change primaryHash → snapshot key changes → no cached snapshot for the new key → offline fetch is skipped → searchResults === undefined → offline blocking view.

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

Stop including columns in primaryHash inside getQueryHashes. Columns are a display‑only concern — the server returns the same records regardless of which columns are visible (note recentSearchHash/similarSearchHash are already computed before columns is appended). Dropping this line so the column set no longer changes queryJSON.hash:

App/src/libs/SearchQueryUtils.ts

Line 533 in 72c2763

orderedQuery += ` ${CONST.SEARCH.SYNTAX_ROOT_KEYS.COLUMNS}:${Array.isArray(query.columns) ? query.columns.join(',') : query.columns}`;

means a column toggle reuses the already‑loaded snapshot and simply re‑renders with the updated visibleColumns. This fixes the offline crash and also removes a redundant Search API round‑trip on every column change while online.

What alternative solutions did you explore? (Optional)

Keep columns in the hash but guard the offline case: when searchResults === undefined and isOffline, render the existing data with the new columns instead of FullPageOfflineBlockingView here:

App/src/components/Search/index.tsx

Lines 1776 to 1779 in 72c2763

	if (searchResults === undefined) {
	Log.alert('[Search] Undefined search type');
	cancelNavigationSpans();
	return <FullPageOfflineBlockingView>{null}</FullPageOfflineBlockingView>;

This avoids the blank page but leaves the unnecessary per‑column snapshots and extra fetches in place, so the hash fix is preferred.

[aswin-s]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[dilshodmackbook-sketch]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.