Reports - Report remains displayed on "Range Filter" results after expense date is changed

[jponikarchuk]

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.36-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: #81897
Email or phone of affected tester (no customers): ibellicotest+2250@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Search

Action Performed:

Prerequisite: Account has at least one worksapce.

1. Open the staging.new.expensify.com website.
2. Open any workspace chat.
3. Create a manual expense with date from today. (03-11)
4. Navigate to "Reports" > "Reports"
5. Click on "Date" filter > "Custom Range"
6. Appy "From" and "To" dates that will trigger the created expense as result. (For example: From 03-09 To 03-11)
7. Note that report of the created expense is correctly displayed as result.
8. Open the report.
9. Change the date of the expense to any date outside of the applied on range filter.
10. Click on the arrow on the top left corner to return to "Reports".
11. Note that report is still displayed on results, despite date being outside of the applied on range filter.

Expected Result:

Report should disappear from results triggered with "Range" filter after the date is edited to any date outside of the applied on the search.

Actual Result:

Report remains displayed on "Range Filter" results after the date of expense on report is edited to any date outside of the applied on the search.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

[melvin-bot]

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

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

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #81897 - "feat/81501: Add Range filter for all date type filters" by @btkcodedev (High confidence)
Related Issues: None

Recommendation: REVERT

The causing PR is clearly identified and introduces a new feature (Range date filter) that has a critical bug. Reverting is the safest approach to unblock deployment while a proper fix is developed.

Labels: No changes needed - DeployBlockerCash is correctly applied (this is a frontend bug blocking the App deploy)

📋 Detailed Analysis

Evidence

• PR feat/81501: Add Range filter for all date type filters #81897 added the Range date filter feature for search
• The issue was detected during regression testing specifically for this PR
• The bug is reproducible only in staging (where this PR was deployed) and not in production
• The issue states "N/A - new feature, doesn't exist in prod"

Verification

The PR modifies search filter functionality, specifically:

• Added CONST.SEARCH.DATE_MODIFIERS.RANGE
• Created new RangeDatePicker component
• Enhanced DateFilterBase, DatePresetFilterBase, and DateSelectPopup to support Range mode
• Modified SearchQueryUtils with 231 additions for range query handling

These changes are directly related to the date filtering feature described in the bug report.

Root Cause

When a user applies a Range filter (e.g., From 03-09 To 03-11) and views the results, the search results are stored in an Onyx snapshot (ONYXKEYS.COLLECTION.SNAPSHOT). When the user then edits an expense date to fall outside that range, the transaction is updated via updateMoneyRequestDate in src/libs/actions/IOU/index.ts. However, there is no logic to:

1. Automatically refresh the search results after a transaction update
2. Optimistically remove items from search results when their criteria no longer match
3. Re-evaluate filter criteria client-side when underlying data changes

The search results remain stale, showing reports that no longer match the applied filter criteria. This is a client-side data synchronization issue between the transaction state and the search snapshot state.

The proper fix would require adding logic to either:

• Trigger a search refresh when transactions are modified
• Optimistically update the search snapshot when transaction dates change
• Add client-side filtering to hide items that no longer match criteria

[MelvinBot]

Proposal

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

When a user applies a custom date range filter on Reports search, opens a report, and edits the expense date to fall outside the applied filter range, the report still appears in the search results after navigating back. The filtered search results are stale and don't reflect the updated transaction data.

What is the root cause of that problem?

There are two contributing factors:

1. updateMoneyRequestDate does not pass the search hash to getUpdateMoneyRequestParams

When a transaction date is edited from a search context, IOURequestStepDate calls updateMoneyRequestDate (src/libs/actions/IOU/index.ts:4879-4918), which calls getUpdateMoneyRequestParams without the hash parameter. The UpdateMoneyRequestDateParams type doesn't even include hash as a field.

Inside getUpdateMoneyRequestParams, there is a block gated by if (hash) (src/libs/actions/IOU/index.ts:4570-4591) that updates the search snapshot in Onyx. Since hash is undefined, this block is skipped entirely. The snapshot (ONYXKEYS.COLLECTION.SNAPSHOT) is never updated when a date is changed.

Notably, other similar functions like updateMoneyRequestTag and updateMoneyRequestCategory do accept and pass hash, showing this is a known pattern that was missed for date updates.

2. The Search component does not refetch results on navigation back

The Search component's main useEffect (src/components/Search/index.tsx:571-598) explicitly excludes isFocused from its dependency array. When the user navigates back to the search results page, isFocused changes but the effect does not re-run, so no refetch is triggered. The stale snapshot continues to be displayed.

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

The fix should ensure the search snapshot is optimistically updated when a transaction date changes from a search context, consistent with how updateMoneyRequestTag and updateMoneyRequestCategory work:

1. Add hash to UpdateMoneyRequestDateParams in src/libs/actions/IOU/index.ts — add hash?: number to the type definition.

2. Pass hash through in updateMoneyRequestDate — forward the hash parameter to getUpdateMoneyRequestParams.

3. Pass the search hash from the caller — in IOURequestStepDate (src/pages/iou/request/step/IOURequestStepDate.tsx), obtain the current search hash from the search context and pass it when calling updateMoneyRequestDate.

4. Update the snapshot's transaction date in getUpdateMoneyRequestParams — the existing if (hash) block only updates violations. It should also update the transaction's created field in the snapshot data so the UI reflects the change immediately. (Alternatively, remove the transaction from the snapshot entirely if determining whether it still matches the filter is too complex.)

What alternative solutions did you explore? (Optional)

• Refetch on focus: Adding isFocused to the Search useEffect dependency array would cause a full API refetch every time the user returns to search results. This is heavier than needed and would cause unnecessary network requests even when no data changed. The optimistic snapshot update approach is more efficient and consistent with existing patterns.

• Clearing the snapshot entirely: Wiping the snapshot when any transaction is edited would work but would cause a flash of empty results followed by a loading state, which is a poor UX.

---

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.