Repository navigation
[Due for payment 2026-10-30] Reset button is not shown when different selector is selected from footer on saved search #104030
Description
If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.
Version Number: 9.5.9-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #100674
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Search
Action Performed:
Precondition:
- Enable spendFooterSelectors beta.
- Go to staging.new.expensify.com
- Go to workspace chat.
- Create an expense.
- Go to Spend > Expenses..
- Click total spend on the footer.
- Click Total.
- Select Reimbursable > Apply.
- Click Save button next to search field.
- Enter name > Save view.
- Go to the saved search from Step 8.
- Click total spend on the footer.
- Click Total.
- Select Billable > Apply.
Expected Result:
Reset button will be shown next to search field when different selector is selected from the footer on saved search (similar to when different filter is applied on saved search).
Actual Result:
Reset button is not shown when different selector is selected from the footer on saved search.
Workaround:
Unknown
Platforms:
- Android: App
- Android: mWeb Chrome
- iOS: App
- iOS: mWeb Safari
- iOS: mWeb Chrome
- Windows: Chrome
- MacOS: Chrome Safari
Screenshots/Videos
Bug7286573_1792002115315.9.mp4
Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7286573
Issue Owner
Current Issue Owner: @mkhutornyiMetadata
Metadata
Assignees
Type
Projects
- Status
Activity
applause-bot commentedon Oct 14, 2026
While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/231c8ca6fe04a74674bc1105785d037c94d20a553555a7ad3ebb2c3678354cb5
melvin-bot commentedon Oct 14, 2026
You have been assigned to this deploy blocker because you recently merged this PR: #100674
melvin-bot commentedon Oct 14, 2026
@JS00001 @mkhutornyi you have been assigned to this deploy blocker because you reviewed the offending PR: #100674
melvin-bot commentedon Oct 14, 2026
@truph01 you have been assigned to this deploy blocker because you authored the offending PR: #100674
github-actions commentedon Oct 14, 2026
👋 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:
melvin-bot commentedon Oct 14, 2026
💬 A slack conversation has been started in #expensify-open-source
JS00001 commentedon Oct 14, 2026
this is behind a beta, lets fix this
1 remaining item
MelvinBot commentedon Oct 14, 2026
Deploy Blocker Investigation
Causing PR: feat: Add count and spend total selectors to the Spend footer (high confidence). It is on the current staging checklist.
Root cause: The PR added
footerCount,footerTotal, andfooterCurrencytoNON_FILTER_CHIP_KEYSin SearchQueryUtils.ts:1217-1223. The Reset check in useSearchFiltersBar.tsx:246 ignores those keys, sofooterTotal:reimbursableandfooterTotal:billablelook identical. Saving does include the footer keys, so a saved view stores the selection but changing it never shows Reset.Recommendation: fix forward, don't revert. The feature is behind the
spendFooterSelectorsbeta. No fix PR exists yet.Recommended fix: For saved searches only, stop ignoring the footer keys in both
hasFiltersChangedFromDefaultandbuildQueryStringWithResetFilters. Reset then shows, and pressing it restores the saved footer selection. Suggested searches keep the PR's intended behavior.Investigation details
canResetcallshasFiltersChangedFromDefault(current, default)with the default ignore set,NON_FILTER_CHIP_KEYS(SearchQueryUtils.ts:1237-1239). For a saved search, the default query is the saved query.buildQueryStringWithResetFilters(SearchQueryUtils.ts:1226-1235) keeps the current footer keys. Even if Reset appeared, it would leavefooterTotal:billablein place.isSearchQuerySavableonly ignoresgroupCurrency(NON_SAVABLE_FILTER_KEYS, L1224). That is why Save and Reset disagree.Suggested change:
SAVED_SEARCH_NON_FILTER_CHIP_KEYSset with onlykeywordandgroupCurrency.ignoredFilterKeysparameter tobuildQueryStringWithResetFilters, matchinghasFiltersChangedFromDefault.useSearchFiltersBar.tsx, pass the saved-search set to both helpers whenisSavedSearchis true. Do the same inSearchAdvancedFiltersProvider.tsx.footerTotal:reimbursable, current query hasfooterTotal:billable. Reset is visible, and pressing it restoresfooterTotal:reimbursable.A simpler option is to remove the footer keys from
NON_FILTER_CHIP_KEYSentirely. That also shows Reset for footer-only changes on suggested searches, which goes against the PR's design. It needs product sign-off.Other candidates: No other PR in this release touches
NON_FILTER_CHIP_KEYSor the Reset logic.Fix status: On Add count and spend total selectors to the Spend footer to let customers choose the data they see, the PR author was asked for one follow-up PR that removes the beta and fixes this issue along with #104010, #104014, and #104026. That PR doesn't exist yet.
view run
truph01 commentedon Oct 15, 2026
@MelvinBot Post proposal
MelvinBot commentedon Oct 15, 2026
Proposal
What is the root cause of that problem?
feat: Add count and spend total selectors to the Spend footer added
footerCount,footerTotal, andfooterCurrencytoNON_FILTER_CHIP_KEYS. The Reset logic ignores every key in that set:canResetcompares the current query with the saved query throughhasFiltersChangedFromDefault. That function skipsNON_FILTER_CHIP_KEYS, sofooterTotal:reimbursableandfooterTotal:billablelook the same.buildQueryStringWithResetFilterskeeps the current footer keys. Even if Reset appeared, it would not restore the saved footer selection.Saving does include the footer keys, because
NON_SAVABLE_FILTER_KEYSonly listsgroupCurrency. So a saved view stores the footer selection, but changing that selection later never counts as a change.Code references
NON_FILTER_CHIP_KEYS: SearchQueryUtils.ts:1217-1224buildQueryStringWithResetFiltersandhasFiltersChangedFromDefault: SearchQueryUtils.ts:1226-1239canReset: useSearchFiltersBar.tsx:236-246.isSavedSearchalready exists at L170.What changes do you think we should make in order to solve the problem?
Treat the footer selection as part of a saved search, but keep today's behavior for suggested searches.
SearchQueryUtils.ts, add a second ignore set for saved searches that holds onlykeywordandgroupCurrency.ignoredFilterKeysparameter tobuildQueryStringWithResetFilters, the same wayhasFiltersChangedFromDefaultalready has one. Default it toNON_FILTER_CHIP_KEYS.useSearchFiltersBar.tsx, whenisSavedSearchis true, pass the saved-search set to bothhasFiltersChangedFromDefaultandbuildQueryStringWithResetFilters.SearchAdvancedFiltersProvider.tsx, do the same. GetcurrentSearchKeyfromuseSearchQueryContext()and check it withsearchKeyToSavedSearchID.footerTotal:reimbursableand a current query withfooterTotal:billable. Reset should show, and pressing it should restorefooterTotal:reimbursable. The existing suggested-search tests stay unchanged.What alternative solutions did you explore? (Optional)
Remove the three footer keys from
NON_FILTER_CHIP_KEYS. This is simpler, but Reset would then also show for footer-only changes on suggested searches. That goes against the design of the original PR and its tests, so it needs product sign-off.Next Steps for Contributor+ team:
To accept:
@MelvinBot implement [this](https://github.com/Expensify/App/issues/104030#issuecomment-6183882623)to create a draft PR.To refine:
@MelvinBot <your feedback>To reject: Explain why you are rejecting Melvin's proposal.
truph01 commentedon Oct 15, 2026
I think this is expected, @JS00001.
The Reset button shouldn't appear or disappear when toggling any of the footer selectors.
JS00001 commentedon Oct 15, 2026
@trjExpensify wydt about this one?
we store the footer currency/selections in the query string so they stick to each view/search. Should changing the footer currency (which changes the query) show 'reset' or not for the search?
trjExpensify commentedon Oct 15, 2026
Oh, I didn't know we're doing this? I don't really love tying in this footer stuff. I was just playing around with it and I'm stuck with this "Save", and I don't really know why.
... I even "Reset" all of the options in the footer popover menu and it didn't do anything. 🤔 Shouldn't that clear it?
If we're showing "Save" in the top bar when you change something in the footer, then you will need to see "Reset" I think otherwise you get stuck like me. As the footer is largely "shown on reveal" then could we just not show save or reset in the header, and make "reset" within the footer work to clear them?
JS00001 commentedon Oct 15, 2026
This feels like what I would expect
trjExpensify commentedon Oct 15, 2026
This part, yeah. 👍
trjExpensify commentedon Oct 19, 2026
@truph01 are you fixing/updating this in #104058?
[-]Reset button is not shown when different selector is selected from footer on saved search[/-][+][Due for payment 2026-10-30] Reset button is not shown when different selector is selected from footer on saved search[/+]melvin-bot commentedon Oct 23, 2026
@mkhutornyi / @truph01
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.5.18-1 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2026-10-30. 🎊
The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the Contributor+ Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]. If no checklist is needed for this issue, you can click: [no checklist button]