[Due for payment 2026-06-23] [Due for payment 2026-06-22] [$250] Android - Unread - Skeleton loader displayed after receiving message from while on "unread"

[unzig21]

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.4.7-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: #92146
Email or phone of affected tester (no customers): ibellicotest+2766@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app)
App Component: Left Hand Navigation (LHN)

Action Performed:

Prerequisite: No existing conversation between User A and User B.
Prerequisite 2: No unread chats.

1. Open the Expensify app as User A.
2. Navigate to "Unread" filter on "Inbox"
3. From another environment or device, start a conversation with User A and send a message.
4. As User A, note that before new chat appears, skeleton loader is briefly displayed and empty state screen is also briefly visible again.

Expected Result:

After receiving a new message while on "Unread" section, new chat should appear automatically without skeleton loader.

Actual Result:

After receiving a new message while on "Unread" filter on "Inbox", skeleton loader is briefly displayed and empty state screen is also briefly visible again, before new chat appears.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7179568_1781318593526.Unread.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022066524447110071225
• Upwork Job ID: 2066524447110071225
• Last Price Increase: 2026-06-15

Issue Owner

Current Issue Owner: @parasharrajat

[melvin-bot]

@Gonals recently merged #92146, but they are OOO right now, so I'll auto-assign someone else.

[melvin-bot]

Triggered auto assignment to @roryabraham (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[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: #92146 - "Inbox filters" by @youssef-lr (High confidence)
Related Issues: None

Recommendation: REVERT

PR #92146 introduced the Inbox filter tabs (All, Unread, To-dos) and its filtering logic causes the LHN to briefly show the skeleton loader and empty state when a new message arrives while the user is on the "Unread" tab. Reverting this PR is the straightforward path since this is a new feature on staging only and no dependent PRs have merged on top of it.

Assigned: @youssef-lr (PR author), @parasharrajat @Gonals (approving reviewers) from highest-confidence causing PR only
Labels: DeployBlockerCash kept (frontend App PR is the cause). DeployBlocker is not present so no change needed.

Detailed Analysis

Evidence

• The issue body explicitly links to PR [Payment due @parasharrajat] Inbox filters #92146 as the relevant change: "If you haven't already ... [Payment due @parasharrajat] Inbox filters #92146"
• The melvin-bot comment also names @Gonals who recently merged PR [Payment due @parasharrajat] Inbox filters #92146
• PR [Payment due @parasharrajat] Inbox filters #92146 is listed in the StagingDeployCash checklist and its merge date (2026-06-12) aligns with the first report of this issue on staging
• The bug is described as "N/A - new feature, doesn't exist in prod", which matches the fact that PR [Payment due @parasharrajat] Inbox filters #92146 introduces a brand-new Inbox filter feature not previously in production
• The affected component is "Left Hand Navigation (LHN)" — exactly what PR [Payment due @parasharrajat] Inbox filters #92146 modifies via src/hooks/useSidebarOrderedReports.tsx, src/libs/SidebarUtils.ts, and src/pages/inbox/sidebar/

Verification

Files affected by the bug:

• src/hooks/useSidebarOrderedReports.tsx — PR [Payment due @parasharrajat] Inbox filters #92146 modifies this file (94 additions, 12 deletions)
• src/libs/SidebarUtils.ts — PR [Payment due @parasharrajat] Inbox filters #92146 adds filterReportsForInboxTab and getIsUnreadReportForInboxTab (82 additions)
• src/pages/inbox/sidebar/SidebarLinks.tsx — the component that renders the skeleton/empty state, passes filteredReports from the context introduced by PR [Payment due @parasharrajat] Inbox filters #92146
• src/pages/inbox/sidebar/BaseSidebarScreen.tsx — PR [Payment due @parasharrajat] Inbox filters #92146 added InboxTabSelector here

All affected files are directly modified by PR #92146.

Root Cause

SidebarLinks shows LHNEmptyState whenever optionListItems.length === 0 (line 92) and shows the skeleton overlay when isLoadingReportData && optionListItems?.length === 0 (line 112).

Before PR #92146, orderedReports was derived from the full unfiltered LHN list. When a new message arrived via Pusher, even if the existing list temporarily recomputed, the incoming report would still be in the base ordered set.

After PR #92146, filteredReports (passed as optionListItems) is the result of filtering orderedReportIDs through filterReportsForInboxTab. When on the "Unread" tab, only reports flagged with isUnreadReport: true in reportsToDisplayInLHN are included. When a new message arrives from an external device:

1. Onyx receives updates for the new report, triggering reportsToDisplayInLHN to recompute incrementally via updateReportsToDisplayInLHN
2. During the brief window when the new chat report has entered orderedReportIDs but its isUnreadReport flag has not yet been set (or is being updated), filteredReportIDs for the Unread tab yields zero results
3. With filteredReports empty, SidebarLinks immediately renders LHNEmptyState
4. isLoadingReportData also briefly goes true during the data refresh, causing the OptionsListSkeletonView to render on top of the empty state
5. Once isUnreadReport: true propagates to reportsToDisplayInLHN, the filter includes the new chat and the list populates again

The stickyReport mechanism introduced in the same PR (which keeps a report visible after it is read) does not apply here because setStickyReportID is only invoked when the user taps a report in the LHN — not when a new report appears via an incoming Pusher message. So there is no protection against this transient empty-list flash when new messages arrive externally.