[Due for payment 2026-06-17] [Due for payment 2026-06-16] Concierge - Concierge chat shows skeleton loader after refresh

[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.0-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: #88769
Email or phone of affected tester (no customers): djnosidjosjos@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Chat Report View

Action Performed:

1. Go to staging.new.expensify.com
2. Open Concierge chat.
3. Refresh the page.

Expected Result:

Concierge chat will not show skeleton loader after refresh (production).

Actual Result:

Concierge chat shows skeleton loader after refresh

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7175012_1780928625240.29.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7175012

[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/b1a43514f628be604223b1f73e065a54582eb58cc10a72fd88ee3ea20c9d6fc4

[melvin-bot]

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

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

This is a regression from #88769 ("Hide read Concierge history in main DM chat"), which is why it reproduces on staging but not production.

That PR extended the Concierge skeleton-loader gate from the side panel to the main DM. The skeleton now shows whenever !hasOnceLoadedReportActions:

• ReportActionsView.tsx:179 — shouldShowSkeletonForConciergePanel = isConciergeHiddenHistory && !hasOnceLoadedReportActions && !isOffline
• useReportActionsVisibility.ts:66 — isConciergeHiddenHistory = isConciergeSidePanel || isConciergeMainDM (previously the gate was isConciergeSidePanel only)

The key detail: hasOnceLoadedReportActions lives in reportLoadingState, which is registered RAM-only (ONYXKEYS.ts:805). So on a page refresh it resets to undefined, and stays falsy until the openReport response returns. During that window the main Concierge DM now renders the skeleton — even though report actions are already cached in Onyx. Before the PR, the main DM had no such gate, so it rendered the cached messages immediately (production behavior). The PR added the skeleton intentionally — "Before the first openReport response, hasOlderActions is unreliable, so we can't determine whether to show the greeting or onboarding messages" — but on the main DM that trade-off surfaces as a visible skeleton flash on every refresh.

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

Stop gating the main DM skeleton purely on hasOnceLoadedReportActions, and instead only show the skeleton when there are no cached actions to render. When the report already has cached actions (the refresh case), render them immediately like production does; only fall back to the skeleton on a genuinely empty/fresh load where the welcome-state vs. history decision can't be made yet.

Concretely, in ReportActionsView.tsx:179, add a "has cached actions" condition so the skeleton is suppressed when sortedReportActions (or the underlying reportActions) is already populated. This preserves the welcome-state behavior on a cold/empty load while restoring instant rendering of cached history on refresh.

What alternative solutions did you explore? (Optional)

• Scope the skeleton back to the side panel only (isConciergeSidePanel), reverting the main-DM portion of the gate. Safest for the deploy blocker, but it weakens the welcome-state computation the PR added for the main DM (risk of briefly flashing wrong content on a true cold load).
• Persist hasOnceLoadedReportActions instead of keeping it RAM-only — rejected; it's intentionally session-scoped and changing that has broad ripple effects beyond Concierge.

Why staging-only / evidence chain

• Reproducible in staging, not production → points to a recently-merged change. PR Hide read Concierge history in main DM chat #88769 merged 2026-06-05 and is the source of this deploy blocker (Melvin auto-assigned the PR author).
• reportLoadingState_ is RAM-only → hasOnceLoadedReportActions does not survive a refresh → skeleton condition isConciergeHiddenHistory && !hasOnceLoadedReportActions is true on every main-DM refresh until openReport resolves.
• Cached report actions exist in persisted Onyx (reportActions_) across refresh, so pre-PR the main DM rendered them with no skeleton.

Related open issues: a quick scan found no duplicate of this skeleton-on-refresh bug (#92364 is a separate Concierge options issue).

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92936) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[Krishna2323]

@MelvinBot implement this

[Krishna2323]

@MelvinBot implement this

[MelvinBot]

🤖 Draft PR created: #92980
Please mark it as "Ready for review" when it is ready for review.