[$250] Android: Tapping push notification on cold start opens last active chat instead of the notification's chat

[melvin-bot]

Description

When the app is cold-started by tapping a push notification (i.e. Android had killed the process while idle), the app navigates to the last active chat rather than the chat referenced in the notification. The correct chat is visible if you press the back button from that screen, meaning the navigation did eventually happen — but underneath the wrong screen.

Reported by dbarrett@expensify.com on Android staging, 2026-05-29 ~13:59 UTC. Tapped a notification from Florent, but the app opened to Chronos (last active chat). Pressing back from Chronos revealed the Florent chat.

Root Cause (confirmed via VictoriaLogs)

This is a cold-start race condition introduced by the dynamic import added in #84624.

subscribeToPushNotifications is now lazily imported inside a useEffect gated on splashScreenState === HIDDEN:

useEffect(() => {
  if (splashScreenState !== HIDDEN) return;
  import('.../subscribeToPushNotifications');
}, [splashScreenState]);

When the user taps a notification to cold-launch the app, the Airship native bridge fires notification_response before the splash screen hides and before PushNotification.onSelected(REPORT_COMMENT, navigateToReport) has been registered. The tap event is dispatched into the void — navigateToReport is never called.

Log Evidence

At 13:59:38.491Z the device correctly emitted:

[PushNotification] Callback triggered for com.airship.notification_response

But none of the subsequent JS-side logs appeared:

• ❌ [PushNotification] Navigating to report
• ❌ [PushNotification] onSelected() - Navigation is ready. Navigating...
• ❌ [PushNotification] Not navigating because this is a singleNewDotEntry flow
• ❌ [PushNotification] onSelected() - failed

Since [PushNotification] Navigating to report is the first line of navigateToReport (before any await or guard), its absence proves the JS handler was never invoked — not just delayed.

Two earlier taps the same day (00:48 UTC and 03:29 UTC, when the app was warm) worked correctly, confirming the regression is specific to cold starts.

Two corroborating signals for cold start:

1. Previous push activity was at 12:44 UTC — 75 minutes of silence before the broken tap, enough for Android to kill the process.
2. A new staging build (ecash9.3.89-2) appeared between the broken tap and the next session, suggesting the 13:59 launch may also have been triggered by an app update.

Steps to Reproduce

1. Open the app on Android, navigate to any chat, then background the app and leave it idle for ~1 hour (or force-kill it).
2. Receive a push notification for a different chat.
3. Tap the notification.

Expected: App opens directly to the notification's chat.
Actual: App opens to the last active chat. The notification's chat is reachable via the back button.

Relevant Code

• subscribeToPushNotifications.ts#L113 — navigateToReport handler
• Related issue: [$250] Defer some non-critical Onyx subscriptions to after the splash screen hides #84624 (the PR that introduced the lazy import gating)

Platform

• Platform: Android
• Environment: Staging (likely also affects production)
• App version at time of report: ecash9.3.83-1

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022060645789472379622
• Upwork Job ID: 2060645789472379622
• Last Price Increase: 2026-05-30

[melvin-bot]

@melvin-bot[bot] the AutoAssignerTriage label has been deprecated. Please use Bug for issue triage. See https://stackoverflowteams.com/c/expensify/questions/14418 for more details.

[MelvinBot]

⚠️ Preliminary analysis (low confidence) — the root cause in the issue body is incorrect for the code at the referenced commit. The reported symptom may still be real, but it is caused by something else.

What the body claims

The body says PR Expensify/App#84390 (linked indirectly via parent issue Expensify/App#84624) gates subscribeToPushNotifications behind a useEffect keyed on splashScreenState === HIDDEN, so the JS-side onSelected(REPORT_COMMENT, navigateToReport) handler is not yet registered when the Airship native bridge fires notification_response on cold start.

Why that doesn't match the code

At the commit referenced in the body (d4cffc8), subscribeToPushNotifications is not in the splash-screen-gated loadPostSplashScreenModules. It is dynamically imported inside setup(), immediately after Onyx.init() and outside the React lifecycle, with a comment explicitly stating it must run before any push arrives — including Android headless wake-ups.

• src/setup/index.ts:78-80 — import('@libs/Notification/PushNotification/subscribeToPushNotifications') runs at module-load, not on splash hide.
• src/SplashScreenStateContext.tsx:26-30 — loadPostSplashScreenModules() defers only replaceOptimisticReportWithActualReport, registerPaginationConfig, UnreadIndicatorUpdater. It does not defer push subscription.

PR Expensify/App#84390's own diff confirms this — subscribeToPushNotifications was added to setup/index.ts, not to the new loadPostSplashScreenModules function:

PR #84390 diff (src/setup/index.ts)

+    // Must be imported after Onyx.init() and outside the React lifecycle so that push notification
+    // handlers are registered before any push arrives, including Android headless/background wake-ups.
+    import('@libs/Notification/PushNotification/subscribeToPushNotifications');

So the "recommended fix" implied by the body (move the import to setup/index.ts) is already shipped. Applying it again is a no-op.

What might actually be happening

I can't fully verify these from code alone — they need log/repro confirmation:

1. Two separate navigations may be racing — navigateToReport at subscribeToPushNotifications.ts:114-153 waits on Navigation.waitForProtectedRoutes() and then Modal.close() before calling Navigation.navigate(...). If the app's deep-link/lastVisitedPath restore (separate from this handler) runs after the notification navigation resolves, the last-active chat would land on top — matching the reported "back reveals Florent (notification chat)" stack order.
2. Headless JS logging — [PushNotification] Navigating to report is logged via Log.info, which posts to the server. If the JS handler ran in a Headless JS context (cold-start background wake) and the process was torn down before the log batch flushed, the log would be missing even though the handler ran. That would invalidate the "handler never ran" inference.
3. Airship deeplink integration — if Airship passes the report route as the app's initial URL, navigation may flow through InitialURLContextProvider rather than (or in addition to) the JS onSelected handler. Worth tracing which path actually fires on Android cold-start tap.

What to check next

• Reproduce the cold-start tap on a current build and capture: (a) whether navigateToReport actually runs (e.g., add a Sentry breadcrumb at the function entry as a stronger signal than Log.info), (b) the Navigation.getActiveRoute() at the moment onSelected fires, (c) whether updateLastVisitedPath is being invoked from another code path after the notification navigation.
• Confirm the staging build at the time of the report (ecash9.3.83-1) actually contains the setup/index.ts:80 line. If staging was on an older Mobile-Expensify submodule pinning a pre-Defer startup imports #84390 App, the original race could be real on staging only — but that's not the file/PR cited.
• Check what restores lastVisitedPath on cold start and at what point in the boot sequence.

Related open issues (quick scan)

• Expensify/App#88158 — push notifications navigation broken for Classic users (different cause — HybridApp routing — but adjacent area).

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis, e.g. point me at a specific log run, a specific App commit, or the Mobile-Expensify submodule SHA the staging build was cut from.

[Abdulloh0109]

Proposal

What is the root cause of that problem?

I traced the cold-start race to two overlapping gaps in src/libs/Notification/PushNotification/subscribeToPushNotifications.ts:22-43 and src/libs/Notification/PushNotification/index.native.ts:41-47.

Gap 1 — init() is gated behind Onyx hydration.
PushNotification.init() — which registers the Airship EventType.NotificationResponse listener — is called at subscribeToPushNotifications.ts:27 inside an Onyx.connectWithoutView callback keyed on ONYXKEYS.NVP_PRIVATE_PUSH_NOTIFICATION_ID. On cold start, Onyx must first read that key from AsyncStorage before the callback fires. Airship fires its notification_response event as soon as the JS bridge is ready, which is well before AsyncStorage I/O completes. Because Airship.addListener(EventType.NotificationResponse, ...) (index.native.ts:71) hasn't been called yet, the native event fires with no JS listener attached — it is completely discarded at the bridge level.

Gap 2 — unhandled NotificationResponse events are silently dropped.
Even in the narrower race (where init() has been called but onSelected hasn't yet bound its handler), pushNotificationEventCallback (index.native.ts:24-56) reaches the !action branch at line 41, logs a Log.warn at lines 43-46, and returns undefined. There is no queue or retry — the tap event is gone.

The two gaps form a sequential "miss window": gap 1 covers the period from native launch until NVP_PRIVATE_PUSH_NOTIFICATION_ID hydrates; gap 2 covers the shorter period between init() and onSelected() registration. On a cold start the full 75-minute-idle scenario in the issue, the phone fires notification_response squarely inside gap 1.

The comment at setup/index.ts:76-78 says the import exists so handlers are "registered before any push arrives", but init() being inside the Onyx callback defeats that intent.

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

Two targeted changes, both in the push notification module.

Change 1 — subscribeToPushNotifications.ts — call init() at module top-level.
Move PushNotification.init() from inside the Onyx.connectWithoutView callback (subscribeToPushNotifications.ts:27) to the top level of the module, so it runs immediately when the module is imported. init() only registers Airship event listeners (index.native.ts:65-74) — it requires no authentication and has no side effects that depend on Onyx state. The register, onReceived, and onSelected calls can remain inside the Onyx callback where they belong (they do need the notificationID). Remove the PushNotification.init() line from inside the callback.

Change 2 — index.native.ts — queue early NotificationResponse events and replay on bind.
Add a module-level array (e.g. pendingNotificationResponses) typed as Array<{eventType: EventType; notification: PushPayload}>. In pushNotificationEventCallback (index.native.ts:24-56), when eventType === EventType.NotificationResponse and the !action branch at line 41 is reached, push {eventType, notification} into the queue instead of just logging and returning. In the bind function (index.native.ts:140-149), after writing actionMap[notificationType] = callback, iterate over pendingNotificationResponses, filter for entries whose eventType and parsed data.type match the newly registered handler, call the action for each match, and remove them from the queue.

Scope: Only subscribeToPushNotifications.ts and index.native.ts are touched. index.web.ts / index.ios.ts / index.android.ts stubs are unaffected. iOS is unaffected in practice (iOS buffers notification_response until the app JS is ready), but the queue in change 2 is harmless there. No changes to navigation, Onyx keys, or authentication.

Edge cases:

• If multiple notifications arrive before any handler registers (unlikely but possible), the queue holds all of them and replays in order.
• If deregister() is called, Airship.removeAllListeners clears the native side; the pendingNotificationResponses array should also be cleared in deregister() (index.native.ts:120-127) to prevent stale replays after sign-out.
• Offline / optimistic rollback: the fix only changes when navigateToReport is invoked — the function's own Navigation.waitForProtectedRoutes() guard (subscribeToPushNotifications.ts:117) already handles the case where navigation is not yet ready.

What alternative solutions did you explore? (Optional)

Retrieve the launch notification after hydration (rejected). Airship's SDK (confirmed via node_modules/@ua/react-native-airship/src/types.ts) does not expose a getLaunchNotification() or getInitialNotification() API to retrieve a cold-start notification after the fact. This avenue is closed.

Await the dynamic import in setup/index.ts (rejected). Making setup/index.ts:78 an await import(...) would block the setup function's async chain on module load, but it would still not fix the race because init() would still be inside the Onyx callback and the Airship event fires from native before JS even begins executing setup. It also risks delaying other setup steps unnecessarily.

Remove the Onyx gating entirely and call init() / onSelected() unconditionally on import (rejected). Calling register() and onSelected() without a valid notificationID would either register the wrong named user or register the navigation handler before session state is ready, risking spurious navigations on sign-out flows. The Onyx gating for register and the handler bindings is correct; only init() needs to move out.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @situchan (External)

[wildan-m]

Proposal

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

When the Android app is cold-started by tapping a push notification (the process had been killed while idle), the app opens the last active chat instead of the chat referenced in the notification. The correct chat is only reachable by pressing the back button, which proves the navigation to it never ran on top — it was the underlying default screen all along.

What is the root cause of that problem?

The push-notification tap handler is never registered in time, so the cold-start tap event is dropped.

On native, a tap is delivered as an Airship NotificationResponse event. The native dispatcher looks the handler up in an in-memory map and, if nothing is bound yet, it logs No callback set up and returns without doing anything — the event is not buffered or replayed:

App/src/libs/Notification/PushNotification/index.native.ts

Lines 41 to 48 in 3ec7273

	const action = actionMap[data.type];
	if (!action) {
	Log.warn('[PushNotification] No callback set up: ', {
	event: eventType,
	notificationType: data.type,
	});
	return;
	}

That map is only populated when subscribeToPushNotifications runs, which binds navigateToReport to the REPORT_COMMENT selected-event via PushNotification.onSelected(...):

App/src/libs/Notification/PushNotification/subscribeToPushNotifications.ts

Lines 20 to 37 in 3ec7273

	*/
	// We do not depend on updates on the UI for notifications, so we can use `connectWithoutView` here.
	Onyx.connectWithoutView({
	key: ONYXKEYS.NVP_PRIVATE_PUSH_NOTIFICATION_ID,
	callback: (notificationID) => {
	if (notificationID) {
	PushNotification.register(notificationID);
	PushNotification.init();
	// Subscribe handlers for different push notification types
	PushNotification.onReceived(PushNotification.TYPE.REPORT_COMMENT, applyOnyxData);
	PushNotification.onSelected(PushNotification.TYPE.REPORT_COMMENT, navigateToReport);
	PushNotification.onReceived(PushNotification.TYPE.REPORT_ACTION, applyOnyxData);
	PushNotification.onSelected(PushNotification.TYPE.REPORT_ACTION, navigateToReport);
	PushNotification.onReceived(PushNotification.TYPE.TRANSACTION, applyOnyxData);
	PushNotification.onSelected(PushNotification.TYPE.TRANSACTION, navigateToReport);

The problem is that subscribeToPushNotifications is pulled in through an asynchronous dynamic import() inside the setup function:

App/src/setup/index.ts

Lines 78 to 80 in 3ec7273

	// Must be imported after Onyx.init() and outside the React lifecycle so that push notification
	// handlers are registered before any push arrives, including Android headless/background wake-ups.
	import('@libs/Notification/PushNotification/subscribeToPushNotifications');

A dynamic import() resolves asynchronously, so evaluating that module — and therefore binding the onSelected handler — is deferred past the synchronous part of startup. On a cold launch triggered by a notification tap, Airship fires the NotificationResponse very early. At that moment the handler map is still empty because the deferred chunk has not finished evaluating, so the dispatcher hits the No callback set up branch and silently drops the tap. The app then continues its normal startup and lands on the last active chat.

This matches the issue's log evidence exactly: the native line Callback triggered for com.airship.notification_response is emitted (the dispatcher ran), but none of the JS handler logs (Navigating to report, onSelected() - Navigation is ready, etc.) appear, because the handler was never bound when the event arrived. It also explains why warm taps work: when the process is already alive the handler is long since registered, so the tap is dispatched correctly. The deferral was effectively present before too — the issue references it as a lazy import gated on splash-screen state — and although that gating has since been refactored, the registration is still deferred today by the asynchronous dynamic import().

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

Register the push-notification handlers synchronously during startup so the onSelected binding exists before any cold-start notification event can be dispatched, while still keeping registration after Onyx.init().

Concretely:

1. In src/libs/Notification/PushNotification/subscribeToPushNotifications.ts, move the two Onyx.connectWithoutView(...) registration blocks (the NVP_PRIVATE_PUSH_NOTIFICATION_ID block that calls register/init/onReceived/onSelected, and the HYBRID_APP block) into an exported function, and export it as the module's default. The helper functions (applyOnyxData, navigateToReport, getLastUpdateIDAppliedToClient) and the module-level isSingleNewDotEntry variable stay where they are; only the side-effecting connect calls move inside the exported function so they run when the function is invoked rather than when the module is first evaluated.

2. In src/setup/index.ts, replace the asynchronous import('@libs/Notification/PushNotification/subscribeToPushNotifications') with a normal static top-of-file import of that default function, and call it synchronously right after Onyx.init() — in the same place the dynamic import currently sits.

This is the exact pattern already used a few lines below for initOnyxDerivedValues(): statically imported and called after Onyx.init(). Because the import is now static, the module is part of the main bundle (no async chunk to wait on), and because the registration is performed by an explicit function call placed after Onyx.init(), the original ordering requirement (handlers registered after Onyx is initialized, outside the React lifecycle) is preserved. The handler map is therefore populated synchronously during setup — before the UI mounts and before the cold-start NotificationResponse is dispatched — so navigateToReport runs and the app opens the notification's chat directly.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/92138-sync-push-notification-subscribe?expand=1

What alternative solutions did you explore? (Optional)

• Buffer/replay the tap on the native side: have pushNotificationEventCallback queue a NotificationResponse whose handler is not yet bound and flush it once onSelected registers. This is more robust against any future deferral, but it adds queueing state and timing complexity to startup-critical native code that is explicitly marked as fragile, when the simpler root-cause fix is to just not defer registration.
• Keep the dynamic import() but await it before allowing startup to proceed past handler registration: this still leaves a window where an early native event could arrive before the awaited import resolves, and it complicates the setup flow; a synchronous static import removes the window entirely.