New Expensify: No expense data or workspaces shown — skeletons persist, OpenApp appears to not complete

[melvin-bot]

Bug Description

When a user opens the New Expensify app (apparently via a Share intent / deep link), the app shows no expenses and no workspaces. Skeleton loaders persist on all tabs including the Account tab. Switching back to Expensify Classic shows all data as expected.

Session here https://app.fullstory.com/ui/o-1WN56P-na1/session/2874836233843617045:613285905765653842!6528747407565211345

Slack convo https://expensify.slack.com/archives/C05LX9D6E07/p1780570754915319

Symptoms

• No expenses displayed
• No workspaces displayed
• Skeleton loaders persist on all tabs (including Account tab)
• All data appears correctly in Expensify Classic
• Appears to be triggered when the app is first opened via a Share action (share intent flow)

Suspected Cause

openApp does not appear to have succeeded or may not have been called at all. The share intent may have bypassed the normal app initialization path, leaving the app in an uninitialized state.

Steps to Reproduce

1. Open New Expensify via a Share intent (e.g. share content from another app)
2. Observe that no expenses or workspaces are shown
3. Skeleton loaders persist on all tabs

Expected Behavior

The app should fully initialize (call openApp) regardless of the entry point, and all expense/workspace data should load normally.

Actual Behavior

App appears stuck in a loading/skeleton state with no data. Switching to Classic shows data is intact.

Platform

Mobile (observed in Portuguese locale)

[MelvinBot]

Issue Analysis

Root cause (mechanism — high confidence): NewDot's skeletons only clear when an OpenApp round-trip completes. IS_LOADING_APP is never seeded in Onyx defaults, and every skeleton consumer reads it with a default of true, so the UI shows "loading" until openApp()'s finallyData explicitly writes IS_LOADING_APP = false (and the response payload delivers reports + personal details). On startup, openApp()/reconnectApp() are dispatched from exactly one place — the mount-only useEffect in AuthScreensInitHandler. If that effect never runs (or runs but no successful OpenApp lands), the app stays skeletonized forever. This matches the reporter's hypothesis that openApp "was never called or never succeeded."

Likely trigger (medium confidence — and it lives outside the App repo): On HybridApp (mobile), AuthScreens (which renders AuthScreensInitHandler) only mounts when hybridApp?.readyToShowAuthScreens === true (AppNavigator.native.tsx:20). That flag is only flipped after the native bridge getHybridAppSettings() returns a non-null payload; if it returns null, HybridAppHandler short-circuits and the flag is never set (HybridAppHandler.tsx:40-46). Whether the native side delivers that payload on a new-expensify://share/root cold launch is implemented in the Mobile-Expensify submodule, not in this repo.

⚠️ One symptom cuts against the simplest version of this: the report says skeletons persist on all tabs including Account, which implies the authenticated tab navigator did render — i.e. AuthScreens mounted. If so, the gate above isn't the cause and the failure is downstream (the else branch ran reconnectApp(), which never clears IS_LOADING_APP, or OpenApp was sent but its response never applied). Production logs are needed to tell these apart — see "How to confirm" below.

Where the fix lives: The decisive trigger (does the native share-intent cold launch hand off to NewDot and prime getHybridAppSettings()?) is in Mobile-Expensify, which isn't part of Expensify/App. This is consistent with the issue's Internal label. This needs an internal engineer with Mobile-Expensify access — I can't propose or implement the native-side fix from here.

Evidence chain (file:line)

Skeletons default to "loading" and only openApp clears them:

• IS_LOADING_APP is not in Onyx initialKeyStates → real value is undefined at boot (setup/index.ts:34-76).
• LHN skeleton gate coerces undefined → true: const [isLoadingApp = true] = useOnyx(ONYXKEYS.IS_LOADING_APP) (BaseSidebarScreen.tsx:24-40); list skeleton mirrors this with IS_LOADING_REPORT_DATA (SidebarLinks.tsx:42-115).
• Only openApp()'s optimistic/finally data writes IS_LOADING_APP = true/false (App.ts:320-379). reconnectApp() only touches IS_LOADING_REPORT_DATA, and calls openApp() solely when !hasLoadedApp (App.ts:474-521).
• Account/Settings tab skeleton is gated separately by isPersonalDetailsEmpty (InitialSettingsPage.tsx:495-507) — but personalDetailsList is delivered by the OpenApp/ReconnectApp response, so it stalls for the same root cause.

Single dispatch site, gated on the HybridApp handshake:

• openApp()/reconnectApp() startup dispatch lives only in the mount-only effect (AuthScreensInitHandler.tsx:114-130); it runs openApp() only when didUserLogInDuringSession() is true, else reconnectApp().
• readyToShowAuthScreens is set inside setupNewDotAfterTransitionFromOldDot (Session/index.ts:776), only reached from HybridAppHandler after a non-null getHybridAppSettings().
• The share-intent deep link itself (DeepLinkHandler → openReportFromDeepLink) does not call openApp for share/root (Link.ts:235-390).

Existing recovery paths don't cover this case:

• DelegateAccessHandler recovery requires hasLoadedApp === true (DelegateAccessHandler.tsx:61-73).
• Reconnect safety net only fires on a later network-reachable / app-foreground transition (Reconnect.ts:40-55).

How to confirm in production (logs disambiguate the two hypotheses)

I attempted a log query but VictoriaLogs wasn't reachable from this run. These verbatim client-side Log.info strings disambiguate gate-vs-downstream:

• Gate (AuthScreens never mounted): [HybridApp] ... getHybridAppSettings called more than once during single NewDot lifecycle. Skipping initialization. present on share-intent sessions, with no following OpenApp/ReconnectApp.
• Downstream (AuthScreens mounted): [AuthScreens] Sending ReconnectApp present → the auth stack mounted, so look instead for an OpenApp/ReconnectApp command that errored or whose response never wrote back IS_LOADING_APP=false.
• Telemetry span SPAN_NAVIGATION.APP_OPEN (App.ts:446-482): its absence proves the init effect never fired.

Filter by the affected account / the pt-BR session if a repro session is attached to the issue.

Possible App-side mitigation (defense-in-depth, not the root fix)

Even after the Mobile-Expensify trigger is fixed, the App is fragile here: there's no fallback that detects "authenticated + app visible + IS_LOADING_APP stuck at undefined/never-loaded" and calls openApp(). The existing Reconnect/DelegateAccessHandler guards both miss this (they require hasLoadedApp === true or a later reachability/foreground event). A targeted recovery — e.g. when currentAccountID is set, the app is online, and HAS_LOADED_APP is still falsy after the auth stack has been mounted for some time → call openApp() — would make NewDot self-heal regardless of entry point. This is App-side and could be done here once prioritized.

Possibly related

• Expensify/App#79389 — "All caught up" + skeleton loading in Inbox after magic-link + 2FA login. Different entry path, but the same failure family (a non-standard entry that leaves openApp/init incomplete → skeletons stuck). Worth checking whether both share the recovery gap above.

---

Confidence: Medium — the skeleton mechanism is firmly evidenced in App code; the share-intent trigger is unconfirmed in logs and the decisive native handoff is in Mobile-Expensify.

Next steps: This is Internal and the trigger lives outside Expensify/App. An internal engineer with Mobile-Expensify access should confirm the native share-intent → getHybridAppSettings() handoff (using the logs above), then fix the native side. Reply with @MelvinBot <feedback> to refine this analysis, or @MelvinBot implement the App-side mitigation if you want me to draft the defense-in-depth recovery in this repo.