Chat - Skeleton loader is displayed when creating room or group chat while 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: 9.1.21-0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers): ibellicotest+467@gmail.com
Issue reported by: Applause - Internal Team

Action Performed:

1. Open the staging.new.expensify.com website
2. Turn off internet connection
3. Tap on the FAB and select "Start Chat"
4. Select "Room"
5. Add a name and complete the creation flow
6. When redirected to chat, turn on internet connection
7. Check the chat behaviour when internet is recovered
8. Turn off internet connection again
9. Tap on FAB and select "Start Chat"
10. Choose some users and start a group chat
11. When redirected to chat, turn on internet connection again
12. Check the group chat behaviour with this action

Expected Result:

Room or group conversations, shouldn´t be reloaded after recovering internet connection

Actual Result:

When creating a room or group conversation while in offline mode, and recovering internet connection, skeleton loader is displayed for some seconds in chat

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6788196_1743445911849.Skeleton.mp4

View all open jobs on GitHub

[melvin-bot]

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

[grgia]

NAB

[thelullabyy]

Proposal

Please re-state the problem that we are trying to solve in this issue.

• When creating a room or group conversation while offline, a skeleton loader is displayed for several seconds upon reconnecting to the internet, even though the conversation already exists locally.

What is the root cause of that problem?

• The skeleton is shown when isLoadingInitialReportActions is true:
  

  App/src/pages/home/report/ReportActionsView.tsx

  Lines 274 to 276 in 003d14f

  	if ((isLoadingInitialReportActions && !isOffline) ?? isLoadingApp) {
  	return <ReportActionsSkeletonView />;
  	}

• isLoadingInitialReportActions is always set to true when the OpenReport API is called, regardless of whether the report is optimistic (i.e., created locally and expected to sync).

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

• We should avoid showing the skeleton loader when the report is optimistic (reportMetadata.isOptimisticReport === true). Optimistic reports are created locally and don’t require initial loading via API, so the skeleton is unnecessary and misleading.

Update the logic at the following location:

App/src/pages/home/report/ReportActionsView.tsx

Line 274 in 003d14f

if ((isLoadingInitialReportActions && !isOffline) ?? isLoadingApp) {

Suggested change:

if ((isLoadingInitialReportActions && !isOffline && !reportMetadata.isOptimisticReport) ?? isLoadingApp) {
    return <ReportActionsSkeletonView />;
}

• Alternatively, we could further scope this behavior to only apply for user-created policy rooms using the isUserCreatedPolicyRoom and isGroupChat utility, if we want to limit the change more narrowly.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

• Add unit tests for the logic that determines whether to show the skeleton loader.
• Mock Onyx data to simulate different combinations of:
  • isLoadingInitialReportActions
  • isOffline
  • reportMetadata.isOptimisticReport
• Validate that the skeleton is only shown when appropriate.

What alternative solutions did you explore? (Optional)

[thelullabyy]

@MonilBhavsar I took a look at the PR you referenced, but I don’t believe that’s the one causing the issue. I think the actual offending PR is this one.

By the way, I’m happy to work on the fix right now if you think my proposal makes sense.