Skip to content

fix: false app hangs when app stops rendering - #8840

Draft
sbs44 wants to merge 1 commit into
getsentry:mainfrom
sbs44:fix/app-hang-v2-false-positives
Draft

sbs44 wants to merge 1 commit into
getsentry:mainfrom
sbs44:fix/app-hang-v2-false-positives

Conversation

@sbs44

@sbs44 sbs44 commented Aug 24, 2026

Copy link
Copy Markdown

📜 Description

V2 infers a blocked main thread purely from missing frames, so any interval where the app is .active but not rendering (CarPlay with the phone locked, a proximity-blanked screen during a call, a missed willResignActive) gets reported as a fully-blocking hang. That's all four fingerprints in #8317, each with idle main-thread stacks.

The fix adds the signal V1 already has: a main-queue heartbeat with an atomic tick counter. Only the synthesized ongoing-frame delay is gated on it... if the main thread is draining its queue and the frame gap exceeds the tracker's sleep interval, the run loop is turning but the display link isn't, so the app isn't rendering and that gap is ignored (for detection and the hang-stop check, via one shared helper). Recorded delayed frames stay fully trusted since they actually rendered, so genuine non-fully-blocking detection is unaffected.

Durations get the same treatment as the existing background exclusion: time without frame delay data (frames tracker paused) and oversleep from OS suspension no longer count toward the reported duration.

Two notes:

  • Error direction is under-report. A main thread genuinely blocked by the OS with the display off (CAMetalLayer nextDrawable... 1 of our 22 original events) still reports, because it really is blocked.
  • Only @_spi(Private) surface changed (SentryFramesDelayResultSPI.ongoingFrameDelayDuration), which isn't in the committed sdk_api*.json... no regen diff.

💡 Motivation and Context

Fixes #8317: thousands of false App Hang Fully Blocked events across four independent fingerprints, durations up to ~24 min matching the non-rendering interval, with no workaround short of disabling hang tracking.

💚 How did you test it?

Unit tests in SentryANRTrackerV2Tests using the existing display link / date provider / dispatch queue doubles (blockBeforeMainBlock, same pattern as the V1 tests). New: the no-rendering repro (responsive main thread + stalled display link → no report), the mixed slow-frame-then-gap variant, hang-stop when the main thread recovers without rendering, and duration exclusion for both no-frame-delay-data and suspension oversleep. Existing genuine-hang tests now block the main thread explicitly; the non-fully-blocking test keeps the heartbeat responsive to guard the jank path. Each new test was run against the unfixed path first and failed for the expected reason.

27/27 in the class, plus V1, FramesTracker, HangTrackingIntegration, Span, and TimeToDisplay (187 tests). make analyze, build-ios, build-macos clean. Our CarPlay fingerprint reproduces on every drive, so we can pin this branch in production and confirm within a day or two.

📝 Checklist

You have to check all boxes before merging:

  • I added tests to verify the changes.
  • No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
  • I updated the docs if needed.
  • I updated the wizard if needed.
  • Review from the native team if needed.
  • No breaking change or entry added to the changelog.
  • No breaking change for hybrid SDKs or communicated to hybrid SDKs.
  • Public API changes reviewed by another Mobile SDK team member or implemented according to the develop docs spec.
  • If I added a new public API, I also added it to the SentryObjC wrapper.

App Hang Tracking V2 misreported non-rendering intervals, e.g. a
CarPlay scene keeping the app alive while the phone is locked, as
fully blocking app hangs. Verify main thread responsiveness with a
V1-style heartbeat before trusting the delay of the ongoing, not
yet rendered frame, and exclude time without frame delay data or
with the app suspended from reported hang durations.

Fixes getsentry#8317
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

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

1 participant