getsentry / sentry-cocoa

The official Sentry SDK for iOS, tvOS, macOS, watchOS.
https://sentry.io/for/cocoa/
MIT License
803 stars 316 forks source link

UIKit VC spans run into timeout if view never becomes visible #2812

Open kahest opened 1 year ago

kahest commented 1 year ago

Problem Statement

If a UIKit VC is initialized, a span is created to capture the lifecycle of the VC. For subsequent passes through UI lifecycle events (viewDidLoad, viewWillAppear, etc.), sub-spans are created.

In cases where the view never becomes visible (i.e. viewWillAppear is never invoked), the main span of the VC runs until the end of the set timeout. This creates non-helpful spans.

Solution Brainstorm

One of the following:

  1. Only report VC spans if they pass at least viewWillAppear
  2. Trim the VC span to the last lifecycle event span

Are you willing to submit a PR?

No response

eric commented 1 year ago

Context: We sometimes initialize a view controller that is later presented when the user does an action (taps on something). This could mean that the child view controller does eventually have viewWillAppear invoked within the timeout (I've seen it after 20 seconds or so), so it's more complicated than just ignoring it if it hits the timeout.

philipphofmann commented 1 year ago

Thanks for the context, @eric 👏 .

brustolin commented 1 year ago

Update: We are currently discussing ways to support this, one of the solutions is to add a special case for ViewControllers spans where they are not waited for. If a root transaction contains a nested view controller span from a view controller that is not attached to the view hierarch, it captures every life cycle that happens while the first one is in progress, but don't need to wait for the second one to appear. If possible, we should add the remaining life cycle events to a UI interaction transaction that triggers them.

philipphofmann commented 1 year ago

This edge case seems like another ducktape fix for our performance implementation. We currently take a step back and reevaluate our approach to performance monitoring on mobile. It could be that we don't need to fix this edge case depending on how the discussions go.