Skip to content

Spend - Inconsistent behavior with Total selector when reopening saved search #104031

Closed
Closed
Spend - Inconsistent behavior with Total selector when reopening saved search#104031
Assignees
JS00001mkhutornyitruph01
Labels
BugSomething is broken. Auto assigns a BugZero manager.EngineeringHourlyKSv2ReviewingHas a PR in review

Description

@applause-bot
applause-bot
bot
opened on Oct 14, 2026

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.
  1. Go to staging.new.expensify.com
  2. Go to workspace chat.
  3. Create an expense.
  4. Go to Spend > Expenses.
  5. Click total spend on the footer.
  6. Click Total > select Reimbursable > Apply.
  7. Click Save button next to search field.
  8. Enter name > Save view.
  9. Go to the saved search from Step 8.
  10. Click total spend on the footer.
  11. Click Total > select Spend > Apply.
  12. Go to Expenses then go back to the saved search.
    → Total is reset to Reimbursable when the previous selector is Spend.
  13. Click total spend on the footer.
  14. Click Total > select Non-reimbursable > Apply.
  15. Go to Expenses then go back to the saved search.
    → Total is not reset to Reimbursable when the previous selector is not Spend.

Expected Result:

In Step 12 and 15, after reopening saved search, total selector should behave the same (reset or not reset to the saved selector).

Actual Result:

In Step 12, when the previous selector is Spend, Total is reset to Reimbursable.
In Step 15, when the previous selector is not Spend, Total is not reset to Reimbursable.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7286579_1792002806824.10.mp4

View all open jobs on GitHub

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

Activity

  1. applause-bot
    added
    DeployBlockerCashThis issue or pull request should block deployment
    BugSomething is broken. Auto assigns a BugZero manager.
    on Oct 14, 2026
  2. gleitebr
    added this to #expensify-bugson Oct 14, 2026

  3. applause-bot commented on Oct 14, 2026

    @applause-bot
    applause-botBot
    on Oct 14, 2026
    Author

    While Applause doesn't embed attachments for this bug, here are the links for quick view:
    https://platform.applause.com/services/links/v1/external/0153a5187d27a96b6b7f4797057c5857553fd8ef825ad9c6df7c92cc1bc69e4c

  4. melvin-bot
    assigned
    JS00001
    on Oct 14, 2026

  5. melvin-bot commented on Oct 14, 2026

    @melvin-bot
    melvin-botBot
    on Oct 14, 2026 – with Melvin Bot

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

  6. melvin-bot commented on Oct 14, 2026

    @melvin-bot
    melvin-botBot
    on Oct 14, 2026 – with Melvin Bot

    @JS00001 @mkhutornyi you have been assigned to this deploy blocker because you reviewed the offending PR: #100674

  7. melvin-bot
    assigned
    mkhutornyi
    on Oct 14, 2026

  8. melvin-bot commented on Oct 14, 2026

    @melvin-bot
    melvin-botBot
    on Oct 14, 2026 – with Melvin Bot

    @truph01 you have been assigned to this deploy blocker because you authored the offending PR: #100674

  9. melvin-bot
    assigned
    truph01
    on Oct 14, 2026

  10. melvin-bot commented on Oct 14, 2026

    @melvin-bot
    melvin-botBot
    on Oct 14, 2026 – with Melvin Bot

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

  11. github-actions
    added
    Engineering
    HourlyKSv2
    on Oct 14, 2026

  12. github-actions commented on Oct 14, 2026

    @github-actions
    github-actionsBot
    on Oct 14, 2026 – with GitHub Actions
    Contributor

    👋 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.

  13. MelvinBot commented on Oct 14, 2026

    @MelvinBot
    MelvinBot
    on Oct 14, 2026
    Contributor

    Deploy Blocker Analysis

    Causing PR: feat: Add count and spend total selectors to the Spend footer (high confidence). No other PR in the current checklist touches the footer, saved-search, or last-query code.

    Root cause: Picking Spend removes the footerTotal filter from the query, because it is the default. When you reopen the saved search, doesQueryMatchDefaultFilterKeysAndType requires every filter key in the saved query to exist in the last query. The saved query has footerTotal:reimbursable, so the last query without footerTotal is rejected, and the app falls back to Reimbursable. Non-reimbursable keeps the footerTotal key, so it passes.

    Recommendation: Roll forward with a small fix. Reverting would back out the whole beta feature (45 files). Ignore footer keys in the key-presence check at SearchQueryUtils.ts:3128, using the existing FOOTER_FILTER_KEYS:

    const defaultQueryFilterKeys = new Set(
    defaultQueryJSON.flatFilters.map((filter) => filter.key).filter((key) => !FOOTER_FILTER_KEYS.has(key)),
);

    With this fix, the last-used footer selection is always restored. This is consistent in both steps 12 and 15.

    Investigation details
    1. getQueryWithFooterSelection skips footerTotal when the value is TOTAL ("Spend"). It also skips footerCount when the value is the type's default count. That query is stored as the saved search's last query.
    2. SavedSearchList.tsx:149 builds the query to open with getValidLastQuery(lastQuery, item.query).
    3. getValidLastQuery returns the saved query whenever a saved filter key is missing from the last query. It checks only that each key is present, not its value.

    Related effects:

    • footerCount has the same bug. Save a view with a non-default count, switch back to the default count, and the view resets.
    • SearchTypeMenuNarrow.tsx uses the same check, so mobile is affected too.
    • The PR already excludes footer keys from the query hash and from filter chips. It missed this check.
    • The other caller, useSearchKeyParam.ts, only checks suggested searches, and their default queries have no footer keys. The fix doesn't change its behavior.

    Alternative: if Product wants a reopened view to always reset to the saved selector, write footerTotal:total out when the saved query has a non-default value. This change is more invasive, because getQueryWithFooterSelection has no access to the saved query.

    A unit test should cover getValidLastQuery(<query without footerTotal>, <saved query with footerTotal:reimbursable>) returning the last query.

    Next Steps: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

  14. JS00001 commented on Oct 14, 2026

    @JS00001
    JS00001
    on Oct 14, 2026
    Contributor

    this is behind a beta, closing btu adding as a follow up

  15. JS00001
    closed this as completedon Oct 14, 2026
  16. github-project-automation
    moved this to Done in #expensify-bugson Oct 14, 2026

  17. truph01 commented on Oct 15, 2026

    @truph01
    truph01
    on Oct 15, 2026
    Contributor

    @MelvinBot Post proposal

  18. MelvinBot commented on Oct 15, 2026

    @MelvinBot
    MelvinBot
    on Oct 15, 2026
    Contributor

    Proposal

    What is the root cause of that problem?

    Spend is the default total, so getQueryWithFooterSelection drops footerTotal from the query when you pick it. That query is stored as the saved search's last query.

    When you reopen the saved search, SavedSearchList.tsx:149 calls getValidLastQuery. Its check, doesQueryMatchDefaultFilterKeysAndType, throws out the last query if any filter key in the saved query is missing from it. The check looks only at which keys are present, not at their values.

    • The saved query has footerTotal:reimbursable.
    • Spend: the last query has no footerTotal key, so the check fails and the app reopens the saved query (Reimbursable).
    • Non-reimbursable: the last query has footerTotal:nonReimbursable. The key is present, so the check passes and the last query is kept.

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

    In doesQueryMatchDefaultFilterKeysAndType, ignore footer keys when building the list of required keys from the default query. Use the existing FOOTER_FILTER_KEYS set for this.

    Footer keys pick what the footer shows. They don't filter rows, so they shouldn't decide whether a last query is still valid. After this change, the last footer choice always comes back when you reopen a saved search. This matches the selections the footer already saves for each search.

    The fix also covers:

    • footerCount, which has the same bug when you switch back to the default count.
    • The narrow layout, because SearchTypeMenuNarrow.tsx:217 uses the same check.

    The other callers check against canned or suggested search queries. Those queries have no footer keys, so their behavior doesn't change.

    Add unit tests for getValidLastQuery:

    • A saved query with footerTotal:reimbursable and a last query without footerTotal returns the last query.
    • A saved query with a non-default footerCount and a last query with the default count returns the last query.
    • Removing a real filter (for example, status) from the last query still returns the saved query.

    What alternative solutions did you explore? (Optional)

    Always reset to the saved selector instead. To do this, write footerTotal:total into the query when you pick Spend and the saved query has a non-default total. This change is larger, because getQueryWithFooterSelection has no access to the saved query. It would also mean a saved search never remembers a footer choice you made later.

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

  19. melvin-bot
    added
    ReviewingHas a PR in review
    on Oct 15, 2026
  20. github-actions
    removed
    DeployBlockerCashThis issue or pull request should block deployment
    on Oct 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

BugSomething is broken. Auto assigns a BugZero manager.EngineeringHourlyKSv2ReviewingHas a PR in review

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions