[Due for payment 2026-05-20] Web - Site crashes when opening report created offline

[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: v9.3.69-0
Reproducible in staging?: Yes
Reproducible in production?: No
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-27379/folder/13176730/41237123/1401519357?sort=%2Bidentifier
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11/ Chrome
App Component: Money Requests

Action Performed:

1. Sign in to staging.new.expensify.com
2. Navigate to a workspace conversation
3. Go offline
4. Create a report
5. Add expense to the report
6. Open the expense created offline

Expected Result:

The expense details is opened

Actual Result:

Site crashes when opening report created offline

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7148507_1778256242659.bandicam_2026-05-08_18-53-34-004.mp4

Bug7148507_1778256242669!staging.new.expensify.com-1778255830884.txt

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ikevin127

[melvin-bot]

Triggered auto assignment to @neil-marcellini (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.

[MelvinBot]

Proposal

What is the root cause of that problem?

PR #51366 ("Open reports at first unread action"), merged 2026-05-08, introduced a skeleton guard in ReportActionsView.tsx:279 that explicitly skips transaction thread reports:

if ((hasDerivedValueTimingIssue || (!isReportTransactionThread && isMissingReportActions)) && !showConciergeSidePanelWelcome) {
    return <ReportActionsSkeletonView shouldAnimate={false} />;
}

The !isReportTransactionThread condition means when a user opens an expense (which navigates to a transaction thread report) created offline, and report actions are missing (isMissingReportActions is true), the skeleton is not shown. Instead, ReportActionsList renders with empty data, causing the crash.

The earlier guards at lines 239-250 also don't catch this because shouldShowSkeletonForInitialLoad requires isLoadingInitialReportActions to be truthy, which may not be set for a purely optimistic offline-created report. And the unread-based guards at lines 259-272 depend on isReportUnread, which returns false for an offline-created report with no lastReadTime.

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

Remove the !isReportTransactionThread exclusion from the skeleton guard at line 279 so that transaction thread reports also show a skeleton when report actions are missing. The condition should be:

if ((hasDerivedValueTimingIssue || isMissingReportActions) && !showConciergeSidePanelWelcome)

This ensures that when a user opens any report (including transaction threads for expenses) with no visible report actions, a skeleton is displayed instead of attempting to render an empty list.

What alternative solutions did you explore? (Optional)

An alternative would be to fix the earlier guard at line 239 to handle offline-created reports that don't have isLoadingInitialReportActions set, but the line 279 guard is the most direct and minimal fix since it already handles the isMissingReportActions case — it just incorrectly excludes transaction threads.

Investigation details

Related deploy blocker: #90032 ("App crashes after reset app and opening expense report") is attributed to the same PR and has the same root cause — missing report actions causing a crash because the skeleton guard doesn't fire for transaction thread reports.

Data flow:

1. User goes offline → creates a report → adds an expense (all optimistic data in Onyx)
2. User opens the offline-created expense → navigates to the transaction thread report
3. ReportActionsView renders → isReportReady is true (unread guards don't fire because no lastReadTime)
4. Line 274 skeleton check passes (report exists, isReportReady is true)
5. Line 279 skeleton guard is skipped because isReportTransactionThread is true
6. ReportActionsList renders with empty sortedVisibleReportActions → crash

Key files:

• ReportActionsView.tsx — the skeleton guards at lines 239-281

---

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.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #51366 - "Open reports at first unread action" by @janicduplessis (Medium confidence)
Related Issues: None identified

Recommendation: REVERT

PR #51366 is the most significant change to the report rendering pipeline in this staging version and is the likely cause of the crash when opening an offline-created expense. Reverting it would restore the previous behavior and unblock this deploy.

Assigned: @janicduplessis (PR author), @ikevin127 @rlinoz (approving reviewers) from PR #51366
Labels: DeployBlockerCash kept (frontend bug in App repo). No label changes needed.

📋 Detailed Analysis

Evidence

• PR Open reports at first unread action #51366 ("Open reports at first unread action") merged on 2026-05-08T12:14:49Z — within the same staging deploy window (v9.3.69-0) where the crash was first observed.
• The bug is staging-only (not reproducible in production), consistent with being introduced by a PR in this cycle.
• PR Open reports at first unread action #51366 is the largest change to the report rendering and pagination pipeline in this release: it touches ReportActionsView.tsx, MoneyRequestReportActionsList.tsx, ReportActionsList.tsx, getReportActionsToDisplay.ts, usePaginatedReportActions.ts, PaginationUtils.ts, useFlashListScrollKey.ts, and several related hooks.
• The crash specifically occurs when opening a report and expense created while offline — the PR contains specific changes to offline action handling (earliestReceivedOfflineMessageIndex, wasMessageReceivedWhileOffline, offline-specific pagination paths).

Verification

Affected files in PR #51366:

• src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx — added resetKey: report.reportID (line 464) to useScrollToEndOnNewMessageReceived. The report variable is declared via useOnyx(...) with as unknown as [OnyxTypes.Report] cast, which suppresses TypeScript's null check. At runtime, if Onyx has not yet populated the optimistic report (race condition during offline creation), report can be undefined, and report.reportID throws TypeError: Cannot read properties of undefined.
• src/pages/inbox/report/getReportActionsToDisplay.ts — new file that blindly calls actions.pop()! (line 62) asserting non-null, and then immediately accesses the result's .pendingAction property. If the actions array is unexpectedly empty for an offline report, this crashes.
• src/hooks/usePaginatedReportActions.ts — new treatAsNoPaginationAnchor path alters which actions are returned for newly created offline reports.
• src/components/FlashList/useFlashListScrollKey.ts — isInitialRender now initializes to !!initialScrollKey instead of always true, changing render behavior for offline reports that have no unread anchor.

The most likely crash site is MoneyRequestReportActionsList.tsx line 464 where report.reportID is accessed directly without optional chaining (report?.reportID). The as unknown as [OnyxTypes.Report] cast at line 100 means TypeScript accepts this, but at runtime an offline-optimistic report might briefly be undefined in the component's own Onyx subscription while the parent guard's snapshot is still valid.

Root Cause

PR #51366 introduced several unsafe property accesses and assumption changes that break for offline-created reports:

1. resetKey: report.reportID in MoneyRequestReportActionsList.tsx relies on the as unknown as [OnyxTypes.Report] TypeScript cast to avoid a null check. If the Onyx value is undefined (offline race condition), this crashes the component.
2. The new getReportActionsToDisplay.ts function uses actions.pop()! with a non-null assertion that could fail for edge-case empty arrays.
3. The useFlashListScrollKey.ts change where isInitialRender is initialized to false when initialScrollKey is falsy changes rendering behavior for offline reports — previously the initial render would go through the deep-link handoff path; now it may not, which can trigger unexpected behavior in the FlatList.

The offline scenario (no network, freshly created optimistic report + expense) exercises these edge cases in ways that online usage does not, explaining why the crash only appears in staging QA's offline regression test.