App Hang Tracking V2 reports false "App Hang Fully Blocked" events when a CarPlay scene keeps the app alive while the phone scene is backgrounded

[sbs44]

Platform

iOS

Environment

Production

Installed

CocoaPods

Other Error Monitoring Solution

No

Other Error Monitoring Solution Name

No response

Version

9.18.0

Xcode Version

EAS Build toolchain (Expo SDK 56 default)

Did it work on previous versions?

Unknown... we see the same false positives across our releases going back ~6 weeks (all on cocoa 9.x with App Hang Tracking V2 default-enabled)

Steps to Reproduce

1. iOS app with the CarPlay entitlement that presents a CPWindow scene (turn-by-turn navigation app), plus background location.
2. Start navigation with CarPlay connected.
3. Lock the phone (or background the phone app) while the CarPlay scene stays active. The process keeps running and rendering CarPlay, but the phone's UIWindowScene stops producing frames.
4. Unlock/foreground the phone minutes later.

A secondary, CarPlay-free variant reproduces with just background location: background the app mid-navigation then resume ~30 minutes later. Hang events (4-6 s) are reported seconds after the foreground/active transition.

Expected Result

No app hang events. The main thread was never blocked... the app was suspended / not rendering the phone scene. At minimum, hang detection should pause while the phone scene is not producing frames due to backgrounding/lock, as it does for the plain UIApplicationDidEnterBackground case.

Actual Result

App Hang Fully Blocked events whose reported duration exactly matches the backgrounded interval... we've received 22 events across 6 users with durations from 2 s up to 521 s (8.7 min). Two of the events are the fatal variant ("The user or the OS watchdog terminated your app while it blocked the main thread for at least 2000 ms"), presumably suspension followed by swipe-kill/jetsam.

Three signals show these are false positives:

1. The main-thread stack in 21/22 events is the idle run loop, not blocked work:

Thread 0 (main):
  mach_msg2_trap
  mach_msg2_internal
  mach_msg_overwrite
  mach_msg
  __CFRunLoopServiceMachPort
  __CFRunLoopRun
  _CFRunLoopRunSpecificWithOptions
  GSEventRunModal
  -[UIApplication _run]
  UIApplicationMain
  ...

(The 22nd event's main thread was waiting in CAMetalLayerPrivateNextDrawableLocked... the phone-side Metal map layer can't vend a drawable while the display is off, which is also a locked-screen symptom rather than a deadlock.)

2. Breadcrumbs bracket the "hang" with a background→foreground gap. Timeline from the 521 s event:

16:39:10 [http]          ... normal navigation traffic (TTS fetches, API calls) ...
16:46:37 [app.lifecycle] {"state":"inactive"}
16:46:37 [app.lifecycle] {"state":"background"}
16:46:39 [http]          last request completes
         --- ~7.5 minutes of silence (app suspended) ---
16:54:06 [app.lifecycle] {"state":"foreground"}
16:54:06 [app.lifecycle] {"state":"active"}
16:54:06 [ui.lifecycle]  {"screen":"CarPlayMapViewController","window":"<CPWindow: ...>", ...}
16:54:24 → event: "App hanging between 521.0 and 521.8 seconds."

The reported duration matches the suspension window, and the first breadcrumb on resume shows the active CPWindow/CarPlayMapViewController scene.

3. contexts.app.in_foreground is true on every event... we suspect the live CarPlay scene keeps UIApplication.applicationState out of .background, defeating the SDK's existing pause-on-background handling for hang tracking (the same handling that was involved in #5907's fix for background launches).

This looks like the CarPlay-scene sibling of #5907 ("App hangs v2 report very high (and invalid) durations", background-launched apps): in both cases the phone UI isn't rendering, V2 sees no frames/heartbeat, and the whole non-rendering interval is attributed to a fully-blocked main thread.

Happy to share full event JSON (stacks, breadcrumbs, contexts) from any of the 22 events privately if useful.

Are you willing to submit a PR?

TBD... but we can definitely test candidate fixes in production (our users hit this on every CarPlay drive)

[linear-code]

COCOA-1611

[philipphofmann]

Thanks for the detailed report, @sbs44 🙏 — this is a well-diagnosed bug and the breadcrumb/stack signals were very helpful.

ℹ️ Investigation done with Claude (Claude Code).

TL;DR

• Confirmed. App Hang Tracking V2 infers "main thread blocked" from a gap in rendered frames. The gap detection assumes foreground + active ⟹ the app should be rendering. That assumption breaks whenever the app is legitimately .active but the display isn't producing frames — a CarPlay scene while the phone screen is dark, or (a second customer report) an in-app phone call where the proximity sensor blanks the screen. The non-rendering interval is then misreported as a fully-blocking hang.
• One correction to the report: contexts.app.in_foreground: true is hardcoded on every app hang event, so it isn't evidence the app was foreground during the hang.
• We already pause detection when the app goes to background or .inactive (frames tracker pauses on willResignActive, fix(v8): Wrong Frame Delay when becoming active (#6381) #6393), so the gap is specifically: the app stays .active while rendering stops.
• Fix is testable without CarPlay hardware or entitlements via the existing V2 test harness.

Technical detail & fix direction

Mechanism. When the frames tracker is running but the CADisplayLink stops, getFramesDelayObjC synthesizes a frame spanning previousFrame→now, giving delay ≈ the full window with framesContributingToDelayCount == 1 → classified fully-blocking (SentryDelayedFramesTracker.m:197-234 → SentryANRTrackerV2.m:226-234).

Why existing guards don't cover it. Detection is gated only by app-aggregate UIApplication state — isApplicationInForeground (background flag) and the frames tracker's pause on willResignActive (.inactive). Neither fires when the app stays .active. There is no scene-level, proximity, or call/audio-session awareness.

Two gaps for phone calls specifically:

• A: an in-app VoIP call keeps the app .active; proximity blanks the display → no willResignActive, frames tracker never pauses → false hang.
• B: even when the app does go .inactive, a hang already in progress isn't cleared, and the duration math excludes only .background time (SentryANRTrackerV2.m:99-139), not .inactive/paused time — so a long interruption inflates the reported duration.

Fix direction: treat "display not rendering" as not-a-hang regardless of why (scene backgrounded, screen off), rather than relying on app-aggregate active state; and exclude .inactive/paused intervals from hang duration the same way .background is excluded.

Repro: deterministic V2 unit test — keep isApplicationInForeground = true, keep the frames tracker running, stall the display-link wrapper past the timeout, advance time → assert a fully-blocking hang is reported today (bug) / not after the fix.