[$250] Reports Disappear from “To Do” Queue When Viewed Without Any Action

[m-natarajan]

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.60-22
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @timothysmall
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Navigate to Reports → To Do
2. Select a report that requires approval or payment
3. Click to open/view the report
4. Do not take any action (no approve/pay)
5. Return to Reports → To Do

Expected Result:

Report should:
Remain in the To Do queue
Stay visible until an action is taken (approve/pay)

Actual Result:

Report is removed from the To Do queue after being viewed

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

The video for the issue is in Slack thread

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @dominictb

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022047732369248472017
• Upwork Job ID: 2047732369248472017
• Last Price Increase: 2026-05-01

[exfy-zapier]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[melvin-bot]

📣 @exfy-zapier! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[MelvinBot]

Proposal

What is the root cause of that problem?

When a user opens a report from the To Do queue, the openReport() function (Report/index.ts:1263) fires the OpenReport API command. While the client-side optimistic data only touches metadata fields (loading flags, reportName), the server response includes an onyxData array that can update any report field — including stateNum and statusNum. This server data is applied first, before client successData (OnyxUpdates.ts:37-46).

The To Do queue is powered by a derived Onyx value (todos.ts) that recomputes whenever ONYXKEYS.COLLECTION.REPORT changes. It categorizes reports into submit/approve/pay/export buckets using isSubmitAction, isApproveAction, isPrimaryPayAction, and isExportAction — all of which gate on stateNum/statusNum.

If the report's state changed server-side between the time the client last synced and when OpenReport fires (e.g., auto-submitted via Delayed/Scheduled Submit, or approved/paid by another user), the server response brings the client up to date. The Onyx merge triggers todos recomputation, and the report no longer qualifies for any bucket — so it vanishes from the To Do list.

Additionally, the To Do search UI uses live Onyx data rather than API snapshots (SearchContext.tsx:127-150), meaning any Onyx update is immediately reflected in the displayed list.

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

The core issue is that the client's local report state can silently drift from the server (e.g., a missed Pusher update, or a server-side auto-submit/approve between syncs), and the user only discovers this when they open the report and OpenReport corrects the state.

Two approaches depending on the actual root cause:

1. If reports are legitimately changing state server-side (Delayed Submit, another approver acting on it): The To Do queue should proactively refresh report states when the list is loaded — not wait for OpenReport to reveal the drift. Calling a lightweight sync when navigating to the To Do view (or periodically refreshing the backing data) would ensure the list accurately reflects server state before the user interacts with individual reports.

2. If the state is NOT actually changing and OpenReport is returning incorrect/stale data: The server-side OpenReport handler needs investigation to determine why it returns different stateNum/statusNum than what the client has.

The first scenario is far more likely. The fix would be to ensure the To Do list data is fresh when displayed, rather than relying on potentially stale local Onyx state that only gets corrected per-report on open.

What alternative solutions did you explore? (Optional)

• Snapshot-based To Do list (like non-todo searches): Instead of live Onyx data, use API-fetched snapshots for the To Do view. This would prevent mid-session disappearances but would also mean the list doesn't update when the user takes action — a worse UX tradeoff.
• Debounce/batch todos recomputation: Delaying recomputation after OpenReport merges could avoid transient inconsistencies, but wouldn't solve the fundamental stale-state problem.

Investigation details

Data flow when a report disappears:

1. User sees report in To Do queue (computed from local Onyx state)
2. User taps report → openReport() fires OpenReport API
3. Server returns onyxData with updated report fields (potentially different stateNum/statusNum)
4. Server data merges into Onyx → triggers ONYXKEYS.DERIVED.TODOS recomputation
5. Report no longer passes isSubmitAction/isApproveAction/isPrimaryPayAction checks
6. User navigates back → report is gone from the list

Key code locations:

• Todo computation: todos.ts:52-86
• State checks: ReportUtils.ts:1978-1984 (isOpenReport, isProcessingReport)
• Server response handling: OnyxUpdates.ts:37-46
• Live data for To Do search: SearchContext.tsx:127-150
• Todo dependencies (9 Onyx collections): todos.ts:91-101

Reproduction note: This is most likely to reproduce on workspaces with Delayed Submit or Scheduled Submit enabled, or where multiple approvers are active — scenarios where server-side report state changes between client syncs.

---

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.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @abzokhattab (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022047732369248472017