[Sentry: APP-JQQ] HybridApp iOS crash opening a universal link — app.keyChain null in TryNewDotManager.navigateToNewDot

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-JQQ

Impact (snapshot at filing)

• Users (last 7d): 5
• Users (total since first seen): 5
• Events: 18
• First seen: 2026-08-02
• Last seen: 2026-08-08
• Platform: iOS (HybridApp)
• App version(s): 9.4.49-3
• Mechanism: nsexception (fatal, uncaught)
• Culprit: -[YAPL logException:], YAPL function navigateToNewDot

Stack trace (top frames, first-party only)

navigateToNewDot@app/libs/TryNewDotManager.js:310:54
    app.keyChain.getPassword
@app/libs/DeepLinkManager.js:53:94

Native frames leading in:

-[ExpensifyAppDelegate application:continueUserActivity:restorationHandler:]
DeepLinkManager.handleUniversalLink
+[YAPLJS callFunction:args:]
-[JSValue callWithArguments:]
-[YAPL logException:]

Suspected cause

Opening a universal link routes through DeepLinkManager.handleUniversalLink, which calls TryNewDotManager.navigateToNewDot. That function reads app.keyChain.getPassword at line 310, and app.keyChain is null at that moment, so the app crashes on the deep link.

continueUserActivity can fire before the app finishes initialising, which would explain a null keychain: the deep link handler runs against a partly constructed app object. Worth confirming whether the crash correlates with a cold start from a link.

The fix is to guard app.keyChain in navigateToNewDot and defer the navigation until initialisation completes, rather than reading through a null.

Reproduction

Unknown. To approximate it: force-quit the app, then open an Expensify universal link so the app cold starts directly into continueUserActivity.

Related

• Expensify/Expensify#669639 — "HybridApp deep link always opens OldDot, ignoring tryNewDot NVP". Same code path (DeepLinkManager into TryNewDotManager), so these two may share a root cause.
• Parent tracker: [Tracking] Top Sentry crashes monthly check-in #91302

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022086528455757581691
• Upwork Job ID: 2086528455757581691
• Last Price Increase: 2026-08-09

[melvin-bot]

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

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022086528455757581691

[MelvinBot]

Issue Analysis

Root Cause (Medium confidence): On a cold start, iOS delivers the universal link through application:continueUserActivity: before the HybridApp shell finishes initialising. That fires DeepLinkManager.handleUniversalLink → TryNewDotManager.navigateToNewDot, which dereferences app.keyChain.getPassword while app.keyChain is still null → fatal uncaught NSException. The reporter's hypothesis in the description matches the stack trace, and the mechanism (deep-link handler running against a partly-constructed app) is self-consistent.

⚠️ The fix is not in this repo — please route it internally. The crashing code (TryNewDotManager.js, DeepLinkManager.js, YAPL bridge) lives in Mobile-Expensify (the OldDot/HybridApp shell), not Expensify/App. I confirmed Expensify/App's src/libs/ has no navigateToNewDot / getPassword — its equivalent is the unrelated src/libs/TryNewDotUtils.ts. Because the fix requires changes in a repo outside App, an External/Upwork contributor can't implement it. This should be handled by an internal engineer with HybridApp access rather than the current external assignment.

Recommended fix direction (for whoever picks it up internally):

1. Null-guard app.keyChain in navigateToNewDot before reading getPassword.
2. If the shell isn't fully initialised yet, queue the pending deep link and replay it once init (keychain) completes, instead of navigating through a null.

Investigation details

• Impact: 5 users / 18 events, iOS HybridApp only, v9.4.49-3, first seen 2026-08-02. Low volume, consistent with a cold-start-from-link race rather than a common path.
• Not reproducible in this environment: this is an iOS-native continueUserActivity cold start. It can't be reproduced on web (or exercised via the JS-only App codebase), so I did not run a UI test — verification needs an iOS device that cold-starts directly into a universal link (force-quit the app, then open an Expensify universal link).
• Could not independently verify line numbers: I don't have read access to Mobile-Expensify, so the :310 / :53 references and the code shape are taken from the crash report, not confirmed against source. That's the main reason this is Medium and not High confidence.
• Related: a related internal issue on the same DeepLinkManager → TryNewDotManager path is already linked in the description; they may share a root cause. Parent tracker is [Tracking] Top Sentry crashes monthly check-in #91302.

---

Next Steps for Contributor+ team:
Because the fix lives in Mobile-Expensify (private), this isn't actionable as an external/Upwork task — please re-route to an internal HybridApp engineer. Reply with @MelvinBot <feedback> to refine this analysis.

[linhvovan29546]

I think @MelvinBot's proposed fix would prevent the crash, but I don't think it's sufficient as described:

1. The null-guard needs to do more than avoid the crash. Simply guarding app.keyChain.getPassword() isn't enough on its own, navigateToNewDot also builds hybridAppSettings.hybridApp.useNewDotSignInPage: !app.isSignedIn(), which is sent to NewDot to tell it whether OldDot already has valid credentials to share. If we guard the keychain access but still report useNewDotSignInPage: false (since isSignedIn() alone is still true), NewDot will assume it can rely on OldDot's session and silently proceed without ever receiving working credentials, trading a crash for a broken, unrecoverable session instead of an actual fix.

2. "Queue the pending deep link and replay once init completes" doesn't match how initialization actually works here. Expensify.getInstance()'s constructor runs entirely synchronously, by the time it returns, keyChain is already either created or permanently null for that session. There's no async initialization step afterward for a queued deep link to usefully wait on; nothing in the normal app flow ever retries keychain creation short of a full fresh sign-in. This isn't a timing/race issue that resolves with a delay, it's a data-consistency gap between authToken and deviceLoginID/keychain that persists indefinitely once triggered.

[MelvinBot]

You're right on both counts — thanks for the correction. I'll retract the "defer and replay" idea and reframe.

On (1) — the guard is insufficient, and the App side confirms why. The NewDot handshake keys entirely off useNewDotSignInPage, so reporting false while OldDot has no shareable credentials produces exactly the silent broken session you describe:

• src/libs/actions/Session/index.ts:685-687 — clearOnyxIfSigningIn() early-returns when !useNewDotSignInPage, so NewDot never redirects to sign-in.
• src/libs/actions/Session/index.ts:783 — sets readyToShowAuthScreens: !useNewDotSignInPage, i.e. it walks straight into the authenticated experience assuming OldDot's session is usable.
• src/libs/HybridApp.ts:89 — signInToOldDotAndChooseExperience() also early-returns when !useNewDotSignInPage, so NewDot won't initiate its own sign-in either.

So the real fix isn't "guard the keychain read" — it's making useNewDotSignInPage reflect actual credential shareability, not just isSignedIn(). When the keychain / deviceLoginID is missing, OldDot should send useNewDotSignInPage: true so NewDot falls back to its own sign-in flow instead of silently trusting a session it will never receive.

On (2) — agreed, it's a data-consistency gap, not a race. If getInstance() is fully synchronous and keychain is either created or permanently null by the time it returns, then there's nothing to wait on and queuing is pointless — I withdraw that. That reframes the underlying question to: how does the app end up with a valid authToken but a null deviceLoginID/keychain, and should that divergence be repaired rather than just handled at read time? Making useNewDotSignInPage credential-aware stops the crash and the broken session, but it treats the symptom; whatever lets the two diverge and persist is worth a separate look (e.g. whether a failed keychain creation should also invalidate the session so they can't drift apart).

Both the navigateToNewDot change and that deeper consistency question live in Mobile-Expensify (private), which I can't read or verify — so I'm deferring to your read of the getInstance() / keychain lifecycle there, and the internal engineer picking this up should own that side. The NewDot-side contract above is the part I can confirm from the public App repo.