[$250] Selected rows are not dropped from the selection count after clearing search filter

[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.4.26-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: #94912
Email or phone of affected tester (no customers): applausetester+ag010726@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11/ Chrome, Samsung S23FE/ Android 16, iPhone 13 Mini/ iOS 26.5
App Component: Workspace Settings

Action Performed:

Preconditions: Have a control workspace with Per diem enabled, and rates added.

1. Navigate to https://staging.new.expensify.com/
2. Log in with any Expensifail account as a workspace admin
3. Go to workspace settings > Per diem
4. Select multiple rows
5. Enter any existing value in the search filter
6. Clear the search filter

Expected Result:

The selected rows are dropped from the selection count.

Actual Result:

The selected rows are not dropped from the selection count.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7197072_1782951508341.step_21.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7197072

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022072577121837881317
• Upwork Job ID: 2072577121837881317
• Last Price Increase: 2026-07-02

Issue Owner

Current Issue Owner: @Krishna2323

[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/b8fb4e50253636a8ca4762dd5725a05c4e09a8aa998f7c2902c55801f9e77b06

[MelvinBot]

Proposal

What is the root cause of that problem?

The Per Diem page keeps its row selection in two stores, and neither one is reconciled against the search string — so selecting rows, searching, then clearing the search leaves the original selection (and its count) fully intact.

• The page tracks selection with useFilteredSelection, which only drops keys that fail its filter callback. Here the filter is (subRate) => !!subRate (always true for existing rows) run against all sub-rates, not the searched subset — so it never removes anything on search. See WorkspacePerDiemPage.tsx:138-140 and useFilteredSelection.ts:12.
• The generic Table selection middleware does auto-clear selection, but only when the dropdown filters change — not when the search string changes. Search on this page goes through Table.SearchBar / isItemInSearch, a separate path that never touches selection. See selection.ts:110 (useEffect(() => clearSelection(), [currentFilters, clearSelection])) and WorkspacePerDiemTable/index.tsx:95-129.

So the selected-count header at WorkspacePerDiemPage.tsx:294 never changes across the search → clear cycle. This is a client-side state-reconciliation gap and is fully reproducible/deterministic (no production logs needed). It surfaced during QA of #94912, which migrated this page to the new Table + SearchBar.

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

Make the shared Table selection middleware reconcile selection when the search string changes, matching the pattern already used for dropdown filters. In src/components/Table/middlewares/selection.ts, pass the active search string into the selection hook and add an effect that resets selection when it changes — mirroring the existing currentFilters effect at line 110. Fixing it in the middleware (rather than the Per Diem page) means every Table.SearchBar + selection list gets consistent behavior; the Per Diem page itself needs no change.

Alternative & considerations

• Prune-to-visible instead of clear-all: remove only selected keys not present in the currently searched data, keeping still-visible selections. This preserves more state but drops rows mid-search as you narrow, and requires care so selections don't silently vanish. The bug report's expectation ("selected rows dropped from the selection count") is satisfied by either approach, but clear-on-search-change is the simpler match to the shipped currentFilters precedent.
• Before landing a generic middleware change, grep for other lists using Table.SearchBar with selection enabled to confirm the new behavior is desirable everywhere.
• No exact duplicate open issues were found; [$250] Spends - Selection mode does not automatically exit when selection count drops to zero #93911 (selection mode not exiting at count 0, closed) is thematically related but a different bug.

What alternative solutions did you explore? (Optional)

See the collapsed section above.

---

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

[kitvasyl]

Proposal

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

Selected per diem rates remain included in the selection count after the user clears the search filter.

What is the root cause of that problem?

In src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx, the SearchBar passes setInputValue directly to onChangeText. Clearing the filter updates filteredSubRatesList, but nothing resets the independently managed selectedPerDiem state, so the header continues counting the previous selections.

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

Add a local search-change handler in WorkspacePerDiemPage that detects the transition from a non-empty inputValue to an empty value, calls setSelectedPerDiem([]), and then calls setInputValue(value). Pass this handler to SearchBar.onChangeText so clearing the search consistently drops the selected rows and updates the count.

What alternative solutions did you explore? (Optional)

A useEffect could observe inputValue, but handling the transition at the search callback is more explicit and avoids clearing selection during unrelated initial renders.

[shivang-goliyan]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-02 07:12:00 UTC.

Proposal

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

On a workspace's Per diem page, if you select some rows, type something into the search box, and then clear the search, the selection count keeps counting rows that are no longer part of what you searched. The count should drop the rows that fell out of view instead of holding onto stale selections.

What is the root cause of that problem?

The selection logic in the new <Table> component reconciles the selected rows when the dropdown filters change, but it never does the same when the search string changes. In src/components/Table/middlewares/selection.ts:110 there's this effect:

// When the table filters change, clear the current selection
useEffect(() => clearSelection(), [currentFilters, clearSelection]);

There is no equivalent effect watching the search string, so typing in or clearing the search bar never prunes selectedKeys. The displayed count comes straight from that unpruned array (WorkspacePerDiemPage.tsx:294 renders translate('workspace.common.selected', {count: selectedSubRateKeys.length})), so it stays inflated.

This can't be fixed from the page either. WorkspacePerDiemPage.tsx:128-140 builds selectableSubRatesByKey from the full set of subrates and passes it to useFilteredSelection, which only drops keys whose row was deleted entirely, not rows hidden by a search. The search string lives inside <Table> (useSearching, a useState('')), so the page has no visibility into which rows are currently searched. The reconciliation has to happen inside the Table. This surfaced with PR #94912, which migrated the Per diem page onto the new composable Table (the PR's own test step 21 spelled out that hidden selected items should drop from the count), and it affects every migrated Table that has both search and selection.

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

Add search-based reconciliation inside useSelection, mirroring the existing filter-clear effect but pruning to the visible set rather than wiping everything. useSelection already receives data as sortedData (the post-search visible rows) at Table.tsx:193, and activeSearchString is already computed at Table.tsx:174, so we pass it in and add:

const previousSearchString = usePrevious(activeSearchString);
useEffect(() => {
    if (previousSearchString === activeSearchString) return;
    const visibleKeys = new Set(data.map((item) => item.keyForList));
    const next = selectedKeys.filter((key) => visibleKeys.has(key));
    if (next.length !== selectedKeys.length) onRowSelectionChange?.(next);
}, [activeSearchString]);

The Table writes the pruned array back through the existing onRowSelectionChange, which is the page's state setter, so the count updates correctly. I'd prune to visible rather than fully clear because step 21 asks for "selected items that are no longer visible" to drop, meaning rows still visible should survive, and because the search bar has no debounce (it fires on every keystroke), so a blanket clearSelection() would wipe the whole selection on the first character typed. Since it's a mechanism fix in the shared component, it also covers the other migrated tables (DomainGroupsTable, etc.) that have the same gap.

I'd also add test coverage here. tests/ui/TableTest.tsx has search and filter describes but no selection-reconciliation tests at all, which is exactly why this shipped broken. Worth adding: select rows, change the search, assert the hidden keys are dropped from onRowSelectionChange; and select rows, clear the search, assert the count.

What alternative solutions did you explore? (Optional)

Fully clearing the selection on search change to exactly match the currentFilters effect. It fixes the repro, but it drops still-visible selected rows too and fires on every keystroke, so it feels too aggressive for a search box; happy to go that route if the team prefers strict consistency with the filter behavior. I also looked at handling this at the page level in useFilteredSelection, but the page never sees the Table's internal search string, so it can't prune by search visibility.

[aswin-s]

Note: This proposal is not a duplicate. It identifies a deeper root cause rather than the surface symptom.

Proposal

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

On the Workspace Per Diem page (Web/Android/iOS), when a user selects multiple rows, enters a value in the table's search bar, then clears the search bar, the selection count in the header still reflects the previously selected rows. Expected behavior: the selection count drops (selection is cleared) once the search interaction changes the visible dataset.

What is the root cause of that problem?

The Table selection middleware only clears the current selection when currentFilters changes (src/components/Table/middlewares/selection.ts:110 — useEffect(() => clearSelection(), [currentFilters, clearSelection])). The search string is tracked in a separate useSearching middleware (src/components/Table/middlewares/searching.ts:56 — activeSearchString) and is NOT included in that effect's dependencies, nor is it passed to useSelection (src/components/Table/Table.tsx:193). Meanwhile useFilteredSelection at src/hooks/useFilteredSelection.ts:13 only prunes selected keys whose entry no longer exists in selectableSubRatesByKey; since typing into / clearing the search bar does not remove entries from selectableSubRatesByKey (built from allSubRates at WorkspacePerDiemPage.tsx:128-136), the selected keys — and therefore the header count consumed at WorkspacePerDiemPage.tsx:270,273,278,294,298 — never change on search enter/clear.

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

1. src/components/Table/middlewares/selection.ts:110 — extend the selection-clearing effect to also react to search-string changes: pass activeSearchString into useSelection and include it in the effect's dependency array so entering/clearing search behaves symmetrically with filter changes.
2. src/components/Table/Table.tsx:193 — forward activeSearchString (already available at line 174) into the useSelection call as a new prop.
3. src/components/Table/middlewares/selection.ts (UseSelectionProps, lines 11-26) — add an activeSearchString: string prop to the type so the search state can be consumed by the effect.
4. Add/adjust unit coverage under src/components/Table/middlewares/ (or table integration tests) to assert that toggling activeSearchString from '' → 'x' → '' triggers onRowSelectionChange([]), matching the filter-change semantics.

What alternative solutions did you explore? (Optional)

Alternatively, clear the selection at the page level via a useEffect on the search string, but centralizing it in the shared Table selection middleware avoids repeating the fix on every consumer (Tags, Distance Rates, Per Diem, etc.).

[KJ21-ENG]

Proposal

What is the root cause of that problem?

The shared table selection middleware clears row selection when dropdown filters change, but it does not clear selection when the table search string changes. Table applies search before selection, then passes only currentFilters into useSelection, so typing or clearing the Per diem search changes the visible row set while leaving selectedKeys unchanged.

App/src/components/Table/Table.tsx

Lines 171 to 194 in 204ddf3

	const {middleware: filterMiddleware, currentFilters, hasActiveFilters, methods: filterMethods} = useFiltering<DataType, FilterKey>({filters, isItemInFilter});
	const filteredData = filterMiddleware(data);
	const {middleware: searchMiddleware, activeSearchString, methods: searchMethods, hasActiveSearchString} = useSearching<DataType>({isItemInSearch});
	const searchedData = searchMiddleware(filteredData);
	const {
	activeSorting,
	methods: sortMethods,
	middleware: sortMiddleware,
	} = useSorting<DataType, ColumnKey>({
	compareItems,
	initialSortColumn,
	narrowLayoutSortColumn,
	shouldUseNarrowTableLayout,
	});
	const sortedData = sortMiddleware(searchedData);
	const {
	methods: selectionMethods,
	mobileSelectionModalRowKey,
	middleware: selectionMiddleware,
	} = useSelection<DataType>({data: sortedData, originalSelectableCount, currentFilters, selectedKeys, onRowSelectionChange});
	const selectionData = selectionMiddleware(sortedData);

App/src/components/Table/middlewares/selection.ts

Lines 109 to 110 in 204ddf3

	// When the table filters change, clear the current selection
	useEffect(() => clearSelection(), [currentFilters, clearSelection]);

The Per diem page stores the selected row keys in selectedSubRateKeys and shows the bulk action button from that array, while WorkspacePerDiemTable enables Table.SearchBar. Because search changes do not reset selection, the selected count can remain after searching and clearing the search.

App/src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx

Lines 270 to 300 in 204ddf3

	if (canWritePerDiem && (shouldUseNarrowLayout ? isMobileSelectionModeEnabled : selectedSubRateKeys.length > 0)) {
	options.push({
	icon: expensifyIcons.Trashcan,
	text: translate('workspace.perDiem.deleteRates', {count: selectedSubRateKeys.length}),
	value: CONST.POLICY.BULK_ACTION_TYPES.DELETE,
	onSelected: async () => {
	const {action} = await showConfirmModal({
	title: translate('workspace.perDiem.deletePerDiemRate'),
	prompt: translate('workspace.perDiem.areYouSureDelete', {count: selectedSubRateKeys.length}),
	confirmText: translate('common.delete'),
	cancelText: translate('common.cancel'),
	danger: true,
	});
	if (action === ModalActions.CONFIRM) {
	handleDeletePerDiemRates();
	}
	},
	});
	return (
	<ButtonWithDropdownMenu
	onPress={() => null}
	shouldAlwaysShowDropdownMenu
	buttonSize={CONST.DROPDOWN_BUTTON_SIZE.MEDIUM}
	customText={translate('workspace.common.selected', {count: selectedSubRateKeys.length})}
	options={options}
	isSplitButton={false}
	style={[shouldDisplayButtonsInSeparateLine && styles.flexGrow1, shouldDisplayButtonsInSeparateLine && styles.mb3]}
	isDisabled={!selectedSubRateKeys.length}
	sentryLabel={CONST.SENTRY_LABEL.WORKSPACE.PER_DIEM.BULK_ACTIONS_DROPDOWN}
	/>

App/src/components/Tables/WorkspacePerDiemTable/index.tsx

Lines 111 to 134 in 204ddf3

	return (
	<Table
	data={perDiemData}
	columns={columns}
	selectionEnabled={selectionEnabled}
	selectedKeys={selectedKeys}
	onRowSelectionChange={onRowSelectionChange}
	renderItem={renderItem}
	keyExtractor={(item) => item.keyForList}
	compareItems={compareItems}
	isItemInSearch={isItemInSearch}
	initialSortColumn="destination"
	narrowLayoutSortColumn="destination"
	title={translate('common.perDiem')}
	>
	{isEmpty && EmptyStateComponent}
	{!isEmpty && (
	<>
	{shouldShowSearchBar && <Table.SearchBar label={translate('workspace.perDiem.findPerDiemRate')} />}
	<Table.Header />
	<Table.Body />
	</>
	)}
	</Table>

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

Pass the table's activeSearchString into useSelection and include it in the selection-reset effect, so changing the search query and clearing it both call clearSelection(), the same way changing dropdown filters already does.

App/src/components/Table/Table.tsx

Lines 174 to 193 in 204ddf3

	const {middleware: searchMiddleware, activeSearchString, methods: searchMethods, hasActiveSearchString} = useSearching<DataType>({isItemInSearch});
	const searchedData = searchMiddleware(filteredData);
	const {
	activeSorting,
	methods: sortMethods,
	middleware: sortMiddleware,
	} = useSorting<DataType, ColumnKey>({
	compareItems,
	initialSortColumn,
	narrowLayoutSortColumn,
	shouldUseNarrowTableLayout,
	});
	const sortedData = sortMiddleware(searchedData);
	const {
	methods: selectionMethods,
	mobileSelectionModalRowKey,
	middleware: selectionMiddleware,
	} = useSelection<DataType>({data: sortedData, originalSelectableCount, currentFilters, selectedKeys, onRowSelectionChange});

App/src/components/Table/middlewares/selection.ts

Lines 11 to 26 in 204ddf3

	type UseSelectionProps<DataType extends TableData> = {
	/** The data being used in the table */
	data: DataType[];
	/** The number of non-disabled items in the original (pre-search/filter) data */
	originalSelectableCount: number;
	/** The list of selected keys */
	selectedKeys: string[];
	/** The list of actively applied filters */
	currentFilters: Record<string, unknown>;
	/** Callback that is fired when the selection of rows in the table changes */
	onRowSelectionChange?: (selectedRowKeys: string[]) => void;
	};

Concretely, extend UseSelectionProps with an activeSearchString string, pass it from Table, and change the existing reset effect to depend on both currentFilters and activeSearchString. This keeps the behavior centralized for all searchable selectable tables, including Per diem, instead of adding a Per diem-only workaround.

Test coverage:

• Add a focused unit/component regression test for a selectable Table with Table.SearchBar: select rows, enter a matching search string, and verify onRowSelectionChange([]) is called; then repeat for clearing a non-empty search string.
• Manually verify Workspace settings > Per diem by selecting multiple rows, entering an existing search value, clearing it, and confirming the selected count/bulk action button disappears on web and mobile layouts.

What alternative solutions did you explore? (Optional)

I considered clearing selectedSubRateKeys directly in WorkspacePerDiemPage, but the bug comes from shared table search/selection state. Fixing Table keeps filter and search behavior consistent for every selectable table that uses the shared component.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-02 07:07:44 UTC.

Proposal

What is the root cause of that problem?

The "Selected (N)" count on the Per Diem page is driven by the page-level state selectedSubRateKeys, whose length is rendered in the bulk-action header here:

• App/src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx

  Line 294 in d4b2e47

  customText={translate('workspace.common.selected', {count: selectedSubRateKeys.length})}

selectedSubRateKeys comes from useFilteredSelection, which only prunes selected keys that fail filterSelectableSubRate, i.e. keys missing from selectableSubRatesByKey:

• App/src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx

  Line 140 in d4b2e47

  const [selectedSubRateKeys, setSelectedSubRateKeys] = useFilteredSelection(selectableSubRatesByKey, filterSelectableSubRate);

• App/src/hooks/useFilteredSelection.ts

  Lines 11 to 15 in d4b2e47

  	function useFilteredSelection<TKey extends string | number, TValue>(options: Record<TKey, TValue> | undefined, filter: (option: TValue | undefined) => boolean) {
  	const [selectedKeys, setSelectedKeys] = useState<TKey[]>([]);
  	const selectedOptions = selectedKeys.filter((key) => filter(options?.[key]));
  	return [selectedOptions, setSelectedKeys] as const;
  	}

selectableSubRatesByKey is built from all of the policy's sub-rates and has no notion of the search text:

• App/src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx

  Lines 128 to 136 in d4b2e47

  	const selectableSubRatesByKey = useMemo(() => {
  	const map: Record<string, SubRateData> = {};
  	for (const subRate of allSubRates) {
  	if (subRate.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
  	map[getPerDiemRowKey(subRate.rateID, subRate.subRateID)] = subRate;
  	}
  	}
  	return map;
  	}, [allSubRates]);

The search text is owned entirely by the Table internally, inside the useSearching middleware, and is never surfaced back to the page. The middleware only narrows the rendered rows:

• App/src/components/Table/middlewares/searching.ts

  Lines 94 to 108 in d4b2e47

  	function search<T>({data, activeSearchString, isItemInSearch}: SearchingMiddlewareParams<T>): T[] {
  	const trimmedSearchString = activeSearchString.trim();
  	if (!isItemInSearch) {
  	// Without a search callback, we keep all items.
  	return data;
  	}
  	if (trimmedSearchString === '') {
  	// Empty search string means no searching should be applied.
  	return data;
  	}
  	return data.filter((item) => isItemInSearch(item, trimmedSearchString));
  	}

• App/src/components/Table/Table.tsx

  Lines 174 to 194 in d4b2e47

  	const {middleware: searchMiddleware, activeSearchString, methods: searchMethods, hasActiveSearchString} = useSearching<DataType>({isItemInSearch});
  	const searchedData = searchMiddleware(filteredData);
  	const {
  	activeSorting,
  	methods: sortMethods,
  	middleware: sortMiddleware,
  	} = useSorting<DataType, ColumnKey>({
  	compareItems,
  	initialSortColumn,
  	narrowLayoutSortColumn,
  	shouldUseNarrowTableLayout,
  	});
  	const sortedData = sortMiddleware(searchedData);
  	const {
  	methods: selectionMethods,
  	mobileSelectionModalRowKey,
  	middleware: selectionMiddleware,
  	} = useSelection<DataType>({data: sortedData, originalSelectableCount, currentFilters, selectedKeys, onRowSelectionChange});
  	const selectionData = selectionMiddleware(sortedData);

So when a row is hidden by the search, nothing removes its key from the selection. The selection middleware does reset the selection when the dropdown filters change, but there is no equivalent handling for the search string changing:

• App/src/components/Table/middlewares/selection.ts

  Lines 109 to 110 in d4b2e47

  	// When the table filters change, clear the current selection
  	useEffect(() => clearSelection(), [currentFilters, clearSelection]);

Because the visible (searched) data is passed into the selection middleware but never used to prune selectedKeys, a row that leaves the visible set stays in the selection.

So: search hides selected rows → the page's selectedSubRateKeys / selectableSubRatesByKey never learn a row left the visible set → useFilteredSelection keeps the hidden keys → the header count at WorkspacePerDiemPage.tsx#L294 never drops the hidden rows, even after the search is cleared.

The same gap exists for every page migrated to the new Table that uses Table.SearchBar + row selection (Categories, Tags, Taxes, Distance rates), since they all keep the count in page state and rely on the shared selection middleware.

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

The selection middleware already receives the currently-visible (filtered + searched) rows as its data argument and already owns the write path back to the parent via onRowSelectionChange:

• App/src/components/Table/middlewares/selection.ts

  Lines 66 to 71 in d4b2e47

  	const selectableKeys = data.filter((item) => !item.disabled && !item.isSelectionDisabled).map((item) => item.keyForList);
  	const tableRowData: Array<TableRow<DataType>> = data.map((item) => ({...item, selected: selectedKeys.includes(item.keyForList)}));
  	const clearSelection = useCallback(() => {
  	onRowSelectionChange?.([]);
  	}, [onRowSelectionChange]);

• App/src/components/Table/Table.tsx

  Lines 193 to 194 in d4b2e47

  	} = useSelection<DataType>({data: sortedData, originalSelectableCount, currentFilters, selectedKeys, onRowSelectionChange});
  	const selectionData = selectionMiddleware(sortedData);

We should reuse that plumbing to drop any selected key that is no longer in the visible data, right next to the existing filter-reset effect at selection.ts#L109-L110:

    // When the table filters change, clear the current selection
    useEffect(() => clearSelection(), [currentFilters, clearSelection]);
+
+   // When the search hides selected rows, drop those hidden rows from the selection
+   const visibleKeys = data.map((item) => item.keyForList).join(',');
+   useEffect(() => {
+       const prunedKeys = selectedKeys.filter((key) => visibleKeys.split(',').includes(key));
+       if (prunedKeys.length === selectedKeys.length) {
+           return;
+       }
+       onRowSelectionChange?.(prunedKeys);
+       // eslint-disable-next-line react-hooks/exhaustive-deps
+   }, [visibleKeys]);

This is a no-op when there is no active search/filter (the visible data then contains every selectable key, so nothing is pruned), and it fixes the root cause once for Per Diem and every other Table-migrated page, so translate('workspace.common.selected', {count}) reflects only rows still in the visible set. The exact key-diffing helper and dependency shape can be tidied in the PR phase.

What alternative solutions did you explore? (Optional)

Add activeSearchString to the existing reset effect at selection.ts#L110 so any search change clears the whole selection (mirroring the filter behavior). This is a one-word change but it also drops rows that are still visible and matched the query, which does not match the expected result ("selected items that are no longer visible are dropped"). Pruning to the visible set is the more precise fix.

[nabi-ebrahimi]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-02 09:25:57 UTC.

Proposal

What is the root cause of that problem?

The Per diem page stores the selected rows in local selectedPerDiem state.

App/src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx

Line 127 in 0eb6bce

const [selectedPerDiem, setSelectedPerDiem] = useState<SubRateData[]>([]);

The search input only updates inputValue, which updates filteredSubRatesList. It does not clear or update selectedPerDiem.

App/src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx

Lines 203 to 208 in 0eb6bce

	const filterRate = useCallback((rate: PolicyOption, searchInput: string) => {
	const results = tokenizedSearch([rate], searchInput, (option) => [option.text ?? '', option.subRateName ?? '']);
	return results.length > 0;
	}, []);
	const sortRates = useCallback((rates: PolicyOption[]) => rates.sort((a, b) => localeCompare(a.text ?? '', b.text ?? '')), [localeCompare]);
	const [inputValue, setInputValue, filteredSubRatesList] = useSearchResults(subRatesList, filterRate, sortRates);

The selected count and selected row IDs still come from selectedPerDiem.

App/src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx

Lines 366 to 395 in 0eb6bce

	danger: true,
	});
	if (action === ModalActions.CONFIRM) {
	handleDeletePerDiemRates();
	}
	},
	});
	return (
	<ButtonWithDropdownMenu
	onPress={() => null}
	shouldAlwaysShowDropdownMenu
	buttonSize={CONST.DROPDOWN_BUTTON_SIZE.MEDIUM}
	customText={translate('workspace.common.selected', {count: selectedPerDiem.length})}
	options={options}
	isSplitButton={false}
	style={[shouldDisplayButtonsInSeparateLine && styles.flexGrow1, shouldDisplayButtonsInSeparateLine && styles.mb3]}
	isDisabled={!selectedPerDiem.length}
	sentryLabel={CONST.SENTRY_LABEL.WORKSPACE.PER_DIEM.BULK_ACTIONS_DROPDOWN}
	/>
	);
	}
	if (secondaryActions.length === 0) {
	return null;
	}
	return (
	<View style={[styles.flexRow, styles.gap2, shouldDisplayButtonsInSeparateLine && styles.mb3]}>
	<ButtonWithDropdownMenu

App/src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx

Lines 445 to 450 in 0eb6bce

	return (
	<AccessOrNotFoundWrapper
	accessVariants={[CONST.POLICY.ACCESS_VARIANTS.ADMIN, CONST.POLICY.ACCESS_VARIANTS.CONTROL]}
	policyID={policyID}
	featureName={CONST.POLICY.MORE_FEATURES.ARE_PER_DIEM_RATES_ENABLED}
	policyFeature={CONST.POLICY.POLICY_FEATURE.PER_DIEM}

So when the user selects rows, searches, and clears the search, the list is restored but the old selectedPerDiem array is still counted.

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

Add a local search-change handler in WorkspacePerDiemPage. When the search changes from non-empty to empty, clear selectedPerDiem, then update the search value as before.

App/src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx

Lines 203 to 208 in 0eb6bce

	const filterRate = useCallback((rate: PolicyOption, searchInput: string) => {
	const results = tokenizedSearch([rate], searchInput, (option) => [option.text ?? '', option.subRateName ?? '']);
	return results.length > 0;
	}, []);
	const sortRates = useCallback((rates: PolicyOption[]) => rates.sort((a, b) => localeCompare(a.text ?? '', b.text ?? '')), [localeCompare]);
	const [inputValue, setInputValue, filteredSubRatesList] = useSearchResults(subRatesList, filterRate, sortRates);

const handleSearchChange = useCallback(
    (value: string) => {
        if (inputValue.trim() && !value.trim()) {
            setSelectedPerDiem([]);
        }

        setInputValue(value);
    },
    [inputValue, setInputValue],
);

Then pass this handler to the existing SearchBar.

App/src/pages/workspace/perDiem/WorkspacePerDiemPage.tsx

Lines 445 to 450 in 0eb6bce

	return (
	<AccessOrNotFoundWrapper
	accessVariants={[CONST.POLICY.ACCESS_VARIANTS.ADMIN, CONST.POLICY.ACCESS_VARIANTS.CONTROL]}
	policyID={policyID}
	featureName={CONST.POLICY.MORE_FEATURES.ARE_PER_DIEM_RATES_ENABLED}
	policyFeature={CONST.POLICY.POLICY_FEATURE.PER_DIEM}

<SearchBar
    ...
    onChangeText={handleSearchChange}
/>

This fixes the root state mismatch directly: clearing the search also clears the state that drives the selected count.

What alternative solutions did you explore? (Optional)

Alternative 1: Clear selection in the shared Table search path

Pass the active search string into the shared table selection middleware and clear selected rows when search changes.

useEffect(() => clearSelection(), [currentFilters, activeSearchString, clearSelection]);

This also fixes the count, but it changes behavior for every searchable selectable table and clears selection while the user is typing, not only when the Per diem search is cleared.

Alternative 2: Prune selected rows to visible rows

Filter selected rows against the current search result.

const visibleSubRateIDs = new Set(filteredSubRatesList.map((subRate) => subRate.subRateID));
setSelectedPerDiem((prev) => prev.filter((subRate) => visibleSubRateIDs.has(subRate.subRateID)));

This avoids counting hidden rows, but it keeps rows selected if they still match the search. The expected result here is clearer if all selected rows are dropped when the search is cleared.

Video demo of fix:

per-diem-fix.mov

[abbasifaizan70]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.