[Due for payment 2026-04-14] [Insights] [$250] Reports - Limit filter is reapplied after resetting filters

[lanitochka17]

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: 9.3.50-2
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-13882/folder/13176922/41237509/1285943533?issue_type=jira&sort=-identifier
Email or phone of affected tester (no customers): sjodijsndoijsodj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Search

Action Performed:

1. Go to staging.new.expensify.com
2. Go to Reports > Expenses.
3. Click Filters.
4. Click Limit.
5. Enter 10 > click Save > View results.
6. Click Filters.
7. Click Reset filters.
8. Click View results.
9. Click Filters.

Expected Result:

Limit field will be cleared.

Actual Result:

Limit filter is reapplied after resetting filters.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7117000_1774880917133.1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @TaduJR

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022038628433322354434
• Upwork Job ID: 2038628433322354434
• Last Price Increase: 2026-03-30

[MelvinBot]

Proposal

What is the root cause of that problem?

When "Reset filters" is clicked, clearAdvancedFilters() correctly sets limit to null in the Onyx form. However, when the query string is rebuilt (on "View results"), buildQueryStringFromFilterFormValues at src/libs/SearchQueryUtils.ts:794 uses:

const limitValue = limit ?? options?.limit;

Since the form's limit is null after clearing, the ?? operator falls through to options?.limit, which is currentQueryJSON?.limit — the old limit value still present in the navigation/URL state. This re-injects the cleared limit back into the query string.

The old limit value comes from AdvancedSearchFilters.tsx:597, which passes limit: currentQueryJSON?.limit as a fallback option when calling buildFilterQueryWithSortDefaults.

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

Stop passing currentQueryJSON?.limit as a fallback option when building the query string from filter form values. Unlike sortBy/sortOrder (which should persist across filter changes), limit is a user-facing filter that appears in the advanced filters UI and should respect the reset action.

The fix should be in buildFilterQueryWithSortDefaults at src/libs/SearchQueryUtils.ts:1711 — remove the limit from the options passed to buildQueryStringFromFilterFormValues. The limit value from the form (filterValues.limit) is already being used directly at line 794 when it's set, so the fallback to options?.limit is what causes it to persist after clearing.

This means removing limit from the currentQueryOptions parameter of buildFilterQueryWithSortDefaults, and removing the limit: currentQueryOptions.limit line at L1711. The callers at AdvancedSearchFilters.tsx:597 and useSearchFiltersBar.tsx:258 would also no longer need to pass limit.

What alternative solutions did you explore? (Optional)

An alternative would be to distinguish between null (explicitly cleared) and undefined (never set) in buildQueryStringFromFilterFormValues — only falling back to options?.limit when limit is undefined, not when it's null. However, this approach is more fragile and less clear in intent. Removing the fallback entirely is simpler since the limit should always come from the form state.

---

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

[melvin-bot]

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

[trasnake87]

Proposal

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

After a user sets a Limit filter on Reports > Expenses, clicking "Reset filters" and then "View results" does not actually clear the limit — it gets silently reapplied to the search query.

What is the root cause of that problem?

The root cause is in the clearAdvancedFilters() function at https://github.com/Expensify/App/blob/main/src/libs/actions/Search.ts#L1400. When filters are reset, the limit key is set to null via the default case in the switch statement. Later, when the query string is rebuilt, the code const limitValue = limit ?? options?.limit uses the nullish coalescing operator — and since null is nullish, it falls through to the old limit value from the URL state. The problem is that null doesn't properly signal "explicitly cleared" to downstream consumers that use ??.

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

We should add an explicit case for FILTER_KEYS.LIMIT in clearAdvancedFilters() that sets it to an empty string '' instead of null. An empty string is not nullish, so '' ?? options?.limit evaluates to '', and the downstream check if (limitValue) correctly treats it as falsy, preventing the limit from being added to the query.

 function clearAdvancedFilters() {
     const values: Partial<Nullable<SearchAdvancedFiltersForm>> = {};
     for (const key of Object.values(FILTER_KEYS)) {
         switch (key) {
             case FILTER_KEYS.COLUMNS:
                 continue;
             case FILTER_KEYS.TYPE:
                 values[key] = CONST.SEARCH.DATA_TYPES.EXPENSE;
                 continue;
             case FILTER_KEYS.STATUS:
                 values[key] = CONST.SEARCH.STATUS.EXPENSE.ALL;
                 continue;
+            case FILTER_KEYS.LIMIT:
+                values[key] = '';
+                continue;
             default:
                 values[key] = null;
         }
     }
     Onyx.merge(ONYXKEYS.FORMS.SEARCH_ADVANCED_FILTERS_FORM, values);
 }

[trasnake87]

Contributor details
Your Expensify account email: trasnake87@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~010f770315ab181656

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[ryntgh]

🚨 Edited by proposal-police: This proposal was edited at 2026-03-30 15:08:22 UTC.

Proposal

What is the root cause of that problem?

After Reset filters, clearAdvancedFilters clears limit with null, so Onyx drops the limit field from SEARCH_ADVANCED_FILTERS_FORM. The advanced filters screen still builds the next query with buildFilterQueryWithSortDefaults, passing limit: currentQueryJSON?.limit from the active search URL.

App/src/libs/SearchQueryUtils.ts

Lines 1708 to 1712 in 29910ea

	const queryString = buildQueryStringFromFilterFormValues(filterValues, {
	sortBy: resetSort || resetSortForViewChange ? undefined : currentQueryOptions.sortBy,
	sortOrder: resetSort || resetSortForViewChange ? undefined : currentQueryOptions.sortOrder,
	limit: currentQueryOptions.limit,
	});

Inside buildQueryStringFromFilterFormValues, the form limit is then undefined, and limit ?? options?.limit reuses that stale URL limit.

App/src/libs/SearchQueryUtils.ts

Lines 794 to 800 in 29910ea

	const limitValue = limit ?? options?.limit;
	if (limitValue) {
	const num = Number(limitValue);
	if (Number.isInteger(num) && num > 0) {
	filtersString.push(`${CONST.SEARCH.SYNTAX_ROOT_KEYS.LIMIT}:${num}`);
	}
	}

When the form is synced from the URL (useSearchFilterSync / buildFilterFormValuesFromQuery), limit is only set if the query has one, so Object.hasOwn(searchAdvancedFilters, 'limit') is a reliable signal that limit is still part of the edited form state. After reset, that key is gone.

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

Only pass the current query limit into buildFilterQueryWithSortDefaults when the form still has an own limit property. If reset removed it, pass undefined so buildQueryStringFromFilterFormValues does not fall back to the old limit.

    const queryString = useMemo(() => {
        const currentQueryJSON = getCurrentSearchQueryJSON();
        const shouldApplyLimitFromCurrentQuery = Object.hasOwn(searchAdvancedFilters, CONST.SEARCH.SYNTAX_ROOT_KEYS.LIMIT);
        return (
            buildFilterQueryWithSortDefaults(
                searchAdvancedFilters,
                {view: currentQueryJSON?.view, groupBy: currentQueryJSON?.groupBy},
                {
                    sortBy: currentQueryJSON?.sortBy,
                    sortOrder: currentQueryJSON?.sortOrder,
                    limit: shouldApplyLimitFromCurrentQuery ? currentQueryJSON?.limit : undefined,
                },
            ) ?? ''
        );
    }, [searchAdvancedFilters]);

App/src/pages/Search/AdvancedSearchFilters.tsx

Lines 591 to 600 in 29910ea

	const queryString = useMemo(() => {
	const currentQueryJSON = getCurrentSearchQueryJSON();
	return (
	buildFilterQueryWithSortDefaults(
	searchAdvancedFilters,
	{view: currentQueryJSON?.view, groupBy: currentQueryJSON?.groupBy},
	{sortBy: currentQueryJSON?.sortBy, sortOrder: currentQueryJSON?.sortOrder, limit: currentQueryJSON?.limit},
	) ?? ''
	);
	}, [searchAdvancedFilters]);

What alternative solutions did you explore? (Optional)

NA

[github-actions]

⚠️ @ryntgh Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).