[Due for payment 2026-04-02] [$250] Report - Unable to select expenses via checkbox after opening thread message and moving expenses

[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.19-0
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-5252/folder/13176730/41237112/1189838851
Email or phone of affected tester (no customers): nojsidjsoidnjdsnjo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create two expenses.
4. Open expense report.
5. Open any expense.
6. Send a message to the expense details page.
7. Right click on the message > Reply in thread.
8. Click header subtitle link to go back.
9. Click header subtitle link again to go back.
10. Select both expenses via checkbox.
11. Click dropdown button > Move expenses.
12. Click Create report.
13. Open workspace chat.
14. Open the new report from Step 12.
15. Click Select all checkbox.

Expected Result:

The expenses will be selected.

Actual Result:

The expenses cannot be selected.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7077279_1771013629602.8.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022026617491589731757
• Upwork Job ID: 2026617491589731757
• Last Price Increase: 2026-03-11

[MelvinBot]

🚨 Edited by proposal-police: This proposal was edited at 2026-02-18 06:00:16 UTC.

Proposal

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

After moving expenses to a new report and navigating to it, the expense checkboxes cannot be selected -- neither individual checkboxes nor "Select all" work.

What is the root cause of that problem?

The root cause is that selectedTransactionIDs in SearchContext (SearchContext.tsx:38) is a single global flat array (string[]) with no report scoping, yet multiple MoneyRequestReportActionsList instances coexist in the navigation stack and all read/write that same global state.

Here's the mechanism:

1. Multiple ReportScreen instances share one global selectedTransactionIDs. The SearchContextProvider wraps all authenticated screens (AuthScreens.tsx:515), and useCustomSplitNavigatorState renders the last 2 central screens simultaneously (createSplitNavigator/index.tsx:33). So when Report A and Report B are both in the stack, both their MoneyRequestReportActionsList instances consume the same selectedTransactionIDs.

2. useFilterSelectedTransactions filters the global IDs against only its own local transactions. At useFilterSelectedTransactions.ts:15-20, the hook filters selectedTransactionIDs to keep only IDs present in its own report's transaction list. When the user selects transaction t3 on Report B, selectedTransactionIDs becomes ['t3']. Report A's still-mounted hook filters ['t3'] against Report A's transactions [t1, t2], gets [], and calls setSelectedTransactions([]) -- wiping the selection.

3. There is no concept of "which report owns the selection". The flat array cannot distinguish selections belonging to different reports, so any mounted instance can destructively modify selections that semantically belong to another report.

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

Scope selectedTransactionIDs by reportID so each report manages only its own selections. Specifically:

1. In SearchContext.tsx, change selectedTransactionIDs: string[] to selectedTransactionIDs: Record<string, string[]> (keyed by reportID).

2. Update setSelectedTransactions to accept a reportID parameter when storing array-type selections, writing to selectedTransactionIDs[reportID] instead of a flat list.

3. Update useFilterSelectedTransactions to accept a reportID parameter and only read/filter selectedTransactionIDs[reportID].

4. Update consumers (MoneyRequestReportTransactionList.toggleTransaction, MoneyReportHeader, useSelectedTransactionsActions) to pass their reportID when reading/writing selections.

5. Update clearSelectedTransactions to support clearing a specific reportID slot or all slots.

This eliminates cross-screen interference entirely because each screen only reads/writes its own slot in the selection map.

What alternative solutions did you explore? (Optional)

1. Move selection state out of SearchContext into component-local state. Since selectedTransactionIDs (array form) is only used by the MoneyRequestReportView family (not the Search page, which uses the object-form selectedTransactions per SearchContext.tsx:307-310), selection could be managed via local useState in MoneyRequestReportActionsList. However, MoneyReportHeader and useSelectedTransactionsActions also read from SearchContext, so they'd need adaptation.

2. Add useIsFocused guard to useFilterSelectedTransactions. This prevents stale screens from modifying selections but doesn't address the architectural issue of a global unscoped array being shared across report instances. It remains fragile if new code consumes selectedTransactionIDs without similar guards.

---

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

[truph01]

Proposal

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

• Users are unable to select expenses in certain scenarios. The selection state is unexpectedly reset, which prevents transactions from remaining selected even though there is no visible change in the underlying transaction data.

What is the root cause of that problem?

• The issue originates from a useEffect that updates the selected transactions whenever the transaction data changes.

• However, the effect is executed even when the current transactions and the previous transactions are effectively the same. As a result, the selection state is recalculated unnecessarily, which can clear or override valid selections and lead to this bug.

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

We should prevent the selection update logic from running when the transaction data has not actually changed. This will both:

• Fix the bug (by avoiding unnecessary state updates).
• Improve performance (by reducing redundant recalculations).

Specifically, we can compare the current and previous transaction lengths and ensure we only update the selection when there is a meaningful difference.

const previousTransactionIDsLength = usePrevious(transactionIDsLength);

const filteredSelectedTransactionIDs = useMemo(
    () => selectedTransactionIDs.filter((id) => transactionIDs.includes(id)),
    [selectedTransactionIDs, transactionIDs],
);

useEffect(() => {
    // Skip if the transaction list length hasn't changed
    // or if filtering doesn't actually remove anything.
    if (
        transactionIDsLength === previousTransactionIDsLength ||
        filteredSelectedTransactionIDs.length === selectedTransactionIDs.length
    ) {
        return;
    }

    setSelectedTransactions(filteredSelectedTransactionIDs);

    // eslint-disable-next-line react-hooks/exhaustive-deps
}, [filteredSelectedTransactionIDs]);

Additionally, this useEffect should run regardless of whether the current screen is focused. There are scenarios where the transaction list may change while the screen is unfocused, and we still need the selection state to remain consistent when the user returns.

What alternative solutions did you explore? (Optional)

[melvin-bot]

Triggered auto assignment to @heyjennahay (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.