[$250] [Sentry: APP-7DX] HybridApp iOS Fatal App Hang in YAPLJS callFunction

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-7DX

Impact (snapshot at filing)

• Users (total since first seen): 467
• Events: 494
• Users (last 14d, 9.4.x releases): 7
• First seen: 2026-03-12
• Last seen: ongoing
• Platform: iOS HybridApp
• App version(s): 9.4.5–9.4.9
• Affected route(s): YAPLJS bridge calls
• Mechanism: AppHang

Stack trace (top frames, first-party only)

+[YAPLJS callFunction:args:]
Fatal App Hang Fully Blocked (main thread blocked 2000ms+)

Suspected cause

Main-thread block during YAPLJS bridge invocation — related hang cluster with APP-7CX (App#91229) and APP-84S but distinct Sentry grouping.

Reproduction

Unknown — see Sentry events linked from the Sentry issue.

Related

• Sibling Sentry IDs: APP-7CX (App#91229), APP-84S
• Prior GH issues: none for APP-7DX

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022067266395600250472
• Upwork Job ID: 2067266395600250472
• Last Price Increase: 2026-07-08

Issue Owner

Current Issue Owner: @jayeshmangwani

[melvin-bot]

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

[melvin-bot]

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

[godzillaxbox19982014-lgtm]

Proposal

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

[$250] [Sentry: APP-7DX] HybridApp iOS Fatal App Hang in YAPLJS callFunction

What is the root cause of that problem?

I traced this to the path that handles APP, 7DX, HybridApp:

• src/libs/HybridApp.ts:95 (if): if (!credentials?.autoGeneratedLogin || !credentials?.autoGeneratedPassword || account?.requiresTwoFactorAuth === undefined || account?.needsTwoFactorAuthSetup === undefined) {
• src/libs/HybridApp.ts:115 (if): if (tryNewDot !== undefined) {
• src/libs/actions/HybridApp/index.ts:23 (if): if (currentTryNewDot !== undefined) {
• The local evidence matches this recurring failure shape: native callback assumes current policy/report still exists. Here, src/libs/HybridApp.ts:95 and src/libs/HybridApp.ts:115 do not agree on the same APP, 7DX, HybridApp value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/libs/HybridApp.ts:95 to derive APP, 7DX, HybridApp from the matched app state path that owns this flow before the value is consumed.
• Carry the same normalized value through src/libs/HybridApp.ts:115; that follows the safer family move to add the guard at the ownership boundary, not only at render, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Sentry Crash, Null/Undefined, Native Hybrid surface and avoid changing do not hide crashes with blanket catch, native platform differences.

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

1. Add or update a regression in tests/unit/**/*.ts for the exact issue flow: [$250] [Sentry: APP-7DX] HybridApp iOS Fatal App Hang in YAPLJS callFunction.
2. Cover the counter-case near src/libs/HybridApp.ts:95 so valid existing APP, 7DX, HybridApp behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep APP, 7DX, HybridApp consistent at the first read/write boundary shown above.

[MelvinBot]

Issue Analysis

Root Cause (high confidence on location, requires internal verification): This is not a NewDot/App-repo bug. YAPLJS callFunction:args: is the native iOS HybridApp bridge that synchronously calls into JS from the iOS main thread. When that bridged call doesn't return within ~2000ms, the iOS watchdog terminates the app and Sentry records it as a Fatal App Hang Fully Blocked. The blocking call originates in native iOS code, which lives outside this repository — there is no YAPLJS symbol anywhere in Expensify/App.

Why this can't be fixed here: The App repo is the React Native/JS side. The hang is a main-thread block in the native HybridApp bridge layer, so any real fix (moving the bridge call off the main thread, adding a timeout/async dispatch, or avoiding the synchronous round-trip) has to happen in the native iOS codebase, not in App.

Recommended next step: Escalate to an internal engineer with access to the native HybridApp codebase. This belongs to the same YAPLJS App-Hang cluster that is already being addressed natively (see related issues below). A separate internal investigation/fix is needed — App-side proposals (including the auto-generated one already on this issue, which references files unrelated to the bridge hang) won't resolve it.

Related issues (same YAPLJS hang cluster)

• [$250] [Sentry: APP-7CX] HybridApp iOS Fatal App Hang in YAPLJS callFunction during onBarButtonItemSelected (still occurring after #86334 closed) #91229 — APP-7CX, YAPLJS callFunction during onBarButtonItemSelected (noted as still occurring after a prior fix closed)
• [$250] [Sentry: APP-84S] HybridApp iOS App Hang in TTGSnackbar YAPLJS callFunction #93841 — APP-84S, YAPLJS callFunction in TTGSnackbar
• [HOLD https://github.com/Expensify/Mobile-Expensify/pull/13970] [$250] [Sentry: APP-7FJ] HybridApp iOS Fatal App Hang at main #91293 — APP-7FJ, Fatal App Hang at main, on HOLD for a native fix PR

These are sibling Sentry groupings of the same underlying problem: a synchronous native→JS bridge call blocking the iOS main thread. Worth tracking them together / deduping.

Investigation details

• grep for YAPLJS across Expensify/App returns zero matches — the crashing symbol is entirely native.
• The stack trace top frame +[YAPLJS callFunction:args:] is an Objective-C class method (+[...]) on the HybridApp bridge, confirming a native main-thread block rather than a JS exception.
• The original umbrella issue for this signature (App#86334, "Fatal App Hang Fully Blocked … main thread for at least 2000 ms") is closed, yet the cluster keeps recurring under distinct Sentry groupings — consistent with the fix needing to land natively.
• Impact snapshot from the issue: 467 users / 494 events since 2026-03-12, 7 users in the last 14 days on 9.4.x — low recent volume but ongoing.

Per the public-repo privacy guard, I'm intentionally not quoting native-repo file paths or code here.

---

Next Steps: This requires a native (non-App) fix — please route to an internal engineer with HybridApp/native iOS access. Reply with @MelvinBot <feedback> to refine this analysis.

[Abdulloh0109]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-17 15:35:49 UTC.

Proposal

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

On iOS HybridApp (Expensify Classic / OldDot), the app fatally hangs: the main thread is blocked 2000ms+ inside +[YAPLJS callFunction:args:] and iOS's watchdog terminates the app. Reported as Sentry APP-7DX on app versions 9.4.5–9.4.9, and flagged as a sibling of the same hang cluster as APP-7CX (#91229) and APP-84S.

What is the root cause of that problem?

This isn't a NewDot (App-repo) bug at all — it's a native main-thread hang inside Expensify Classic (OldDot), and it's the same cluster that's already being worked in #91229.

The Sentry signature is an AppHang: the main thread sits inside +[YAPLJS callFunction:args:] for 2000ms+ and iOS's watchdog kills the app. YAPLJS is the OldDot bridge that synchronously enters the YAPL JavaScriptCore context. The moment that synchronous call holds the JSC VM lock on the main thread past ~2s — whether from a re-entrant JS call, lock contention, or heavy inline work — the watchdog fires. None of that runs on NewDot's React Native JS thread; it's a separate VM living entirely in the Mobile-Expensify submodule.

APP-7DX is explicitly filed as a sibling of APP-7CX (#91229) and APP-84S — "related hang cluster ... but distinct Sentry grouping." In #91229 the full stack is unambiguous:

-[BaseViewController onBarButtonItemSelected:]
  → +[YAPLJS callFunction:args:]          // JSC lock acquired on main thread
    → +[YAPLLogManager logWithLevel:...] → LogSyncerManager.sendLogPacket
      → +[YAPLJS callFunction:args:]      // second entry, same thread
        → JSC::JSLock::lockSlow → ParkingLot::parkConditionallyImpl → _pthread_cond_wait

i.e. the main thread parks waiting for the JSC lock it already holds — a same-thread re-entrancy deadlock. APP-7DX shares the culprit frame (+[YAPLJS callFunction:args:], fully-blocked main thread, 2s watchdog) but the snapshot here only gives that top frame, so I won't claim the inner LogSyncerManager sub-stack is identical for this grouping — it may enter YAPL from a different action. What is certain is the layer: a synchronous YAPLJS.callFunction holding the JSC lock on the main thread.

Why the App repo can't carry the fix: per the HybridApp philosophy doc, OldDot iOS native code lives in Mobile-Expensify/iOS and the YAPL JS logic in Mobile-Expensify/app — HYBRID-APP.md#L18-L21. The bridge ships from the local module wired up in package.json#L96 and ios/Podfile.lock#L4712, but YAPLJS, YAPLLogManager, and LogSyncerManager themselves are not in this repo.

For the record, the existing proposal on this issue points at src/libs/HybridApp.ts (the NewDot tryNewDot/sign-in flow) with blob/HEAD/ links. That's the wrong layer and the wrong VM — that TypeScript runs on NewDot's RN JS thread, never on the OldDot JSC main-thread path that the watchdog is killing. It can't be the cause of a +[YAPLJS callFunction:args:] hang.

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

Track this under #91229's fix rather than re-solving it. The durable fix is native, in Mobile-Expensify, at the +[YAPLJS callFunction:args:] boundary: make synchronous native→JS entry non-re-entrant on the main thread — guard the bridge so a nested call from within an active JS frame is deferred/queued (drained after the outer call unwinds) instead of parking on the JSC lock. That neutralizes the whole YAPLJS → YAPLLogManager → LogSyncerManager → YAPLJS family in one place, which is exactly the lever a per-grouping fix can't reach.

@mateuuszzzzz already has this in flight for #91229 — Mobile-Expensify #13970 and #13971 — and @mountiny approved a "give it a try and monitor in Sentry" rollout on 2026-06-17. Concretely I'd suggest:

1. Link APP-7DX to [$250] [Sentry: APP-7CX] HybridApp iOS Fatal App Hang in YAPLJS callFunction during onBarButtonItemSelected (still occurring after #86334 closed) #91229 and ship those PRs first.
2. After they reach production, watch APP-7DX in Sentry alongside APP-7CX / APP-84S. The bridge-level guard should drop all of them together.
3. Only if APP-7DX keeps firing on 9.4.x after the guard lands do we treat it as a separate root cause — at which point the next step is reading the full per-event stacks in APP-7DX (not the one-frame snapshot) to find which JS entry point still re-enters or blocks. I'd hold off opening a parallel investigation until that data says the shared fix didn't catch it.

No App-repo (NewDot) change is warranted. The only NewDot-side lever that could even matter is the volume of OldDot logging triggered around NewDot↔OldDot transitions, and throttling that would be a fragile band-aid over a native re-entrancy bug — not the fix.

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

These tests belong in Mobile-Expensify (native iOS), since that's where the bridge lives — there's no App-repo (NewDot) test surface that exercises YAPLJS:

1. Re-entrancy guard: invoke a YAPL JS function via YAPLJS.callFunction that, mid-execution on the main thread, triggers a second native→JS call (e.g. through the logging path YAPLLogManager → LogSyncerManager.sendLogPacket). Assert the nested call is deferred/queued and drained after the outer call unwinds, and that the main thread is never blocked on the JSC lock.
2. Main-thread budget: assert that a YAPLJS.callFunction invocation triggered from a UI action returns well under the 2000ms watchdog threshold, so a regression that reintroduces synchronous re-entry or heavy inline work fails the test instead of shipping.
3. Ordering preserved: confirm deferred log packets are delivered in FIFO order after the outer JS call completes, so the non-re-entrant path doesn't drop or reorder logs.

What alternative solutions did you explore? (Optional)

• Fix it in NewDot src/libs/HybridApp.ts (the existing proposal's direction). Rejected: that module is React Native TypeScript on a different JS VM and never appears on the native JSC hang path. Reverting any change there would not reproduce or prevent a +[YAPLJS callFunction:args:] watchdog kill.
• Patch the specific caller (LogSyncerManager.sendLogPacket) to dispatch its YAPL callback off the current stack. Reasonable and matches one of the [$250] [Sentry: APP-7CX] HybridApp iOS Fatal App Hang in YAPLJS callFunction during onBarButtonItemSelected (still occurring after #86334 closed) #91229 proposals, but it's caller-by-caller whack-a-mole; a re-entrancy guard at the YAPLJS.callFunction boundary covers every present and future native path that re-enters JS, which is why [$250] [Sentry: APP-7CX] HybridApp iOS Fatal App Hang in YAPLJS callFunction during onBarButtonItemSelected (still occurring after #86334 closed) #91229 landed on the bridge-level approach.
• Treat APP-7DX as a wholly independent bug and pinpoint a new native root cause now. Rejected on evidence: the issue itself groups it with APP-7CX/APP-84S, the culprit frame is identical, and Mobile-Expensify is private so no contributor can give line-level native permalinks here regardless. Spinning up a separate bounty before the shared fix is validated in Sentry just duplicates in-flight work.

[github-actions]

⚠️ @Abdulloh0109 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[github-actions]

⚠️ @Abdulloh0109 Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.