Spend - Filters are not updated after changing Type filter, Type filter not applied

[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: 9.3.82-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #90029
Email or phone of affected tester (no customers): jodijojosjojso@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 15 Pro Max / iOS 26.5
App Component: Search

Action Performed:

Scenario 1:

1. Launch Expensify app.
2. Go to Spend > Expenses.
3. Tap Filters.
4. Tap Type
5. Select Expense Report > Confirm.
6. Tap Status.
7. Select Draft > Confirm.
8. Tap Apply Filters.

Scenario 2:

1. Launch Expensify app.
2. Go to Spend > Expenses.
3. Tap Filters.
4. Tap Type
5. Select Chat > Confirm.

Expected Result:

Scenario 1:
In Step 7, Status should not include Unreported and Deleted after selecting Expense Report.
In Step 8, Draft status should be applied after tapping Apply Filters.

Scenario 2:
Expense filters should not appear after selecting Chat type filter.

Actual Result:

Scenario 1:
In Step 7, Status includes Unreported and Deleted after selecting Expense Report.
In Step 8, Draft status is not applied after tapping Apply Filters.

Scenario 2:
Expense filters are shown after selecting Chat type filter.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Scenario_1

Bug7163053_1779753302349.Scenario_1.mp4

Scenario_2

Bug7163053_1779753302349.Scenario_2.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7163053

[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/813ed10db4860529c3969705b156ea83cf7c5f63c4a79d98b349e02c17dc9fab

https://platform.applause.com/services/links/v1/external/33f0381e565c39864e3ebdc1ac572460574a830ad9c3f981c6c8fd904f6f8540

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #90029

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

What is the root cause of that problem?

Both MultiSelectFilterComponents and useAdvancedSearchFilters read the current type from the Onyx form (SEARCH_ADVANCED_FILTERS_FORM) to determine which status options to display and which filters are visible. However, when the user changes the Type filter, Onyx is not updated synchronously:

• Popup flow: updateFilterQueryParams updates the URL via Navigation.setParams, but the Onyx form only syncs back asynchronously through useSearchFilterSync. During this stale window, status options and filter list visibility still reflect the old type.
• Fullscreen flow: AdvancedFiltersFullscreen stores the type change in local useState, but Onyx is only written on "Apply Filters". Meanwhile, MultiSelectFilterComponents reads type from Onyx (stale) to build status options, and useAdvancedSearchFilters reads type from Onyx (stale) to determine which filters to show.

This explains all three symptoms:

1. Wrong status options — status options are built from stale Onyx type
2. Draft not applied — user selects a status that's valid for the old type but gets filtered out or ignored for the new type on apply
3. Expense filters shown for Chat — filter list visibility reads stale type from Onyx

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

Pass the current type as a prop through the component tree instead of having MultiSelectFilterComponents and useAdvancedSearchFilters independently read it from Onyx:

1. useAdvancedSearchFilters: Accept an optional typeOverride parameter. When provided, use it instead of reading from Onyx. Both AdvancedFiltersFullscreen and AdvancedFiltersPopup already know the current type from their local state/values — pass it through.

2. MultiSelectFilterComponents: Accept an optional type prop. When provided, use it instead of the Onyx useOnyx call. SelectedFilterContent / CommonContent already receive values which contains the current type — thread it down.

This eliminates the stale-Onyx dependency for both flows without changing the data sync architecture.

What alternative solutions did you explore? (Optional)

An alternative would be to have updateFilterQueryParams write directly to the Onyx form in addition to updating the URL, removing the async gap. This would fix the popup flow but not the fullscreen flow (which intentionally defers Onyx writes until "Apply"). The prop-threading approach fixes both flows uniformly.

---

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.

[godzillaxbox19982014-lgtm]

One concrete detail to include in the fix: the Draft loss is specifically from the final fullscreen Apply path, not only from stale status options.

After the user stages type: "expense-report" and status: ["drafts"], useUpdateFilterQuery() merges those local values with the old Onyx form, then the type !== searchAdvancedFiltersForm.type branch immediately overwrites that explicit status with CONST.SEARCH.STATUS.EXPENSE.ALL:

App/src/components/Search/hooks/useUpdateFilterQuery.tsx

Lines 17 to 27 in dd15fd9

	function updateFilterQueryParams(values: Partial<SearchAdvancedFiltersForm>) {
	const updatedFilterFormValues: Partial<SearchAdvancedFiltersForm> = {
	...searchAdvancedFiltersForm,
	...values,
	};
	if (updatedFilterFormValues.type !== searchAdvancedFiltersForm.type) {
	updatedFilterFormValues.columns = [];
	updatedFilterFormValues.status = CONST.SEARCH.STATUS.EXPENSE.ALL;
	updatedFilterFormValues.has = filterValidHasValues(updatedFilterFormValues.has, updatedFilterFormValues.type, translate);
	}

So the before/after token is type:expense-report status:drafts -> type:expense-report with no status. The fix should either perform the type-change cleanup when Type is changed in the local fullscreen values, or make the final Apply skip the automatic status reset when the submitted values already include a status selected after the type change.