Skeleton loader is always shown when opening/refreshing ND

[mitarachim]

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.3.11-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-3776/folder/13176924/41237549/1155362915?p=2
Email or phone of affected tester (no customers): sdjosindjosnjdiosj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.1 / Chrome
App Component: Other

Action Performed:

1. Go to staging.new.expensify.com
2. Refresh the page or open ND in a new tab.

Expected Result:

App will load instantly without skeleton loader.

Actual Result:

Skeleton loader is always shown when opening/refreshing ND.

If the page is refreshed while on self DM view, it shows fallback avatar with no self DM name.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7060793_1769650849872.7.mp4

Bug7060793_1769650728237.7.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @mallenexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

Triggered auto assignment to @JS00001 (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: #79764 - "Added new spans for bootsplashvisible" by @BartekObudzinski (High confidence)
Related Issues: #79955 (the issue this PR was intended to fix)

Recommendation: REVERT

PR #79764 should be reverted. While it was intended to add telemetry spans for performance tracking, it inadvertently broke the app initialization timing, causing skeleton loaders to persist on every page load/refresh.

Labels: Removing DeployBlocker label (this blocks the backend/Web deploy but does not affect the App). Keeping DeployBlockerCash label (this blocks the App deploy).

Detailed Analysis

Evidence

PR #79764 was merged on January 27, 2026 at 17:27:42 UTC. The bug was reported on staging on January 29, reproducing consistently on web (MacOS Chrome/Safari). The bug does NOT reproduce in production, confirming it was introduced by a staging-only PR.

Root Cause

The PR made two critical changes to src/components/LocaleContextProvider.tsx that broke the app initialization sequence:

Change 1: Delayed IntlStore.load() execution

• Before PR Added new spans for bootsplashvisible #79764: IntlStore.load(localeToApply) was called OUTSIDE the useEffect (executed immediately during render)
• After PR Added new spans for bootsplashvisible #79764: IntlStore.load(localeToApply) moved INSIDE the useEffect (only executes after component mounts)

This delay means translations are no longer loaded synchronously during the initial render, causing the app to proceed with initialization before locale data is ready.

Change 2: Premature locale span completion

• Before: endSpan(CONST.TELEMETRY.SPAN_BOOTSPLASH.LOCALE) was called in LocaleContextProvider when !areTranslationsLoading
• After: endSpan(CONST.TELEMETRY.SPAN_BOOTSPLASH.LOCALE) is called in Expensify.tsx when preferredLocale exists

The new timing ends the locale span before translations are actually loaded and ready, breaking the synchronization between locale readiness and app initialization.

Impact

When the app initializes:

1. The locale span ends prematurely (when preferredLocale exists, not when translations load)
2. The app thinks locale is ready and proceeds with navigation
3. But IntlStore.load() is delayed until after component mount
4. Content cannot render without translations, so skeleton loaders persist
5. Eventually translations load and skeleton loaders disappear, but this creates a poor UX

This affects every app open/refresh on web, as shown in the issue videos.

Verification

Files modified by PR #79764 that caused the regression:

• src/components/LocaleContextProvider.tsx - Changed IntlStore.load() timing (line 111)
• src/Expensify.tsx - Changed when locale span ends (lines 191-196)

The PR also modified src/libs/Navigation/NavigationRoot.tsx removing an && !isTransitioning condition (line 141), but this appears unrelated to the skeleton loader issue.