[Due for payment 2026-07-17] Expense - Skeleton loader appears briefly after creating expense in the empty report

[applause-bot]

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.32-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: #95045
Email or phone of affected tester (no customers): sidbhisdhidhisdhis@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an empty report.
4. Open the report.
5. Create an expense inside the report.

Expected Result:

Skeleton loader will not appear after creating expense in the empty report.

Actual Result:

Skeleton loader appears briefly after creating expense in the empty report.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7203758_1783599285975.5.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7203758

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/0bd5efe862c6509ec350d7bd500bfc20742571236416f7233c0ce30bf22c7703

[melvin-bot]

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

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

Issue Analysis

TL;DR: PR #95045 (the PR this deploy blocker was auto-assigned to) is very unlikely to be the cause. Its changes are purely FlashList scroll-positioning and it does not touch any of the code that controls the skeleton loader's visibility. The transient skeleton is gated by a data-readiness state that flips while the first expense is created.

Why it's not #95045: The skeleton (ReportActionsSkeletonView) and the FlashList are mutually-exclusive siblings — ReportActionsSkeletonGuard renders the skeleton instead of the list. Which one shows is decided entirely by computeReportActionsSkeletonState, whose inputs are all data-readiness signals (isLoadingInitialReportActions, isMissingReportActions, isSingleExpenseReport, isOffline, …). None of them read initialScrollIndex or FlashList paint timing. #95045 only edits scroll files (useReportActionsScroll.ts, ReportActionsList.tsx, the flash-list patch, etc.) — none of the three skeleton-gating files. Even the new "delayed first paint" patch behavior happens inside the already-mounted list, so it can only yield a blank list frame, never re-show the skeleton.

Most likely cause: A data-readiness flip in computeReportActionsSkeletonState at the moment the expense is created:

• isReportDataIncomplete = isSingleExpenseReport && isMissingTransactionThreadReportID — creating the first expense makes childMoneyRequestCount === 1 (so isSingleExpenseReport → true) for a frame before the transaction-thread report ID populates, which (with a transient isLoadingInitialReportActions) trips shouldShowSkeletonForInitialLoad. This is the strongest candidate.
• Or hasDerivedValueTimingIssue = reportActionsLength > 0 && isMissingReportActions — a window where raw actions exist but the derived sortedVisibleReportActions is momentarily empty during recompute.

Recommended next step: Since this is time-sensitive, I'd suggest not reverting #95045 based on this. Instead, look at which PR in this StagingDeployCash actually touched the report-actions loading / skeleton logic (ReportActionsListContext.tsx, useReportActionsListModel.ts, ReportActionsSkeletonGuard.tsx), and confirm on staging with a debugger whether the skeleton coincides with isSingleExpenseReport && !transactionThreadReport?.reportID. Production logs / a screen recording with those state values would confirm the exact trigger.

Investigation details

Confidence: High that #95045 is not the cause (based on its diff + the structural independence of skeleton vs. scroll code). Medium on the exact root cause, since I did not capture runtime state.

Key references:

• Skeleton-vs-content gate: ReportActionsSkeletonGuard.tsx:31-64
• Skeleton state computation: ReportActionsListContext.tsx:44-119 (:84, :86, :109, :112)
• isMissingReportActions / isSingleExpenseReport: useReportActionsListModel.ts
• Open linked message at top - 3 #95045 scroll positioning (unrelated to skeleton): useReportActionsScroll.ts:415-423

Alternatives considered & ruled out:

• Open linked message at top - 3 #95045's initialScrollIndex delaying first paint → the delay is internal to the mounted FlashList, which sits in the guard's children; it cannot bring the skeleton back. Would show a blank list, not a skeleton.
• Report type flipping shouldFocusToTopOnMount on expense creation → shouldReportAlignToTop is type-based (money-request report), not a function of whether expenses exist, so it doesn't flip when the expense is added.
• List remount when initialScrollIndex changes → the list is keyed by key={listID}, not initialScrollIndex, so no remount occurs.

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis (e.g. point me at the other PRs in this deploy and I can narrow down which one changed the skeleton logic).