Feat: Manual Tracing

[denrase]

Overview

• Introduce manual tracing for stateful widgets
• Introduce manual tracing to sync of orgs and projects

Motivation

We want to dog-food this feature and see which path we have to automatic tracing. So more suggestions, for example for app start or slow/frozen frames are more than welcome!

Closes https://github.com/getsentry/sentry-mobile/issues/219

Assets

[denrase]

@ueman Would be great to also have your thoughts on this. 🙇

[ueman]

@denrase You could additionally enable HTTP tracing with the SentryHttpClient.

[denrase]

@marandaneto

• Http tracking does work. I also changed the time when we are staring the org/projects sync for the main page, so that it is part of that transaction. However, first render of the widget is done before the http requests are finished, so the transaction is cut off before everything is ready.

• Getting the name of the widgets state with runtimeType.toString() also works as expected, but I have also introduced a method to provide a custom name.

• Also went through flutter docs once more. I don't think we have much else to go by than the post frame callback for stateful widgets. Couldn't even find if post frame callbacks frame of reference is certainly associated with the rendering of the current widget, but it's how this API is used everywhere where I have looked, so I'm assuming this is correct.

• There is other API to get durations for frame rendering and rasterisation, so we could observe the performance of the whole application. But it looks like this is not specifically to a widget.

[ueman]

• Http tracking does work. I also changed the time when we are staring the org/projects sync for the main page, so that it is part of that transaction. However, first render of the widget is done before the http requests are finished, so the transaction is cut off before everything is ready.

It only works if a transaction is bound to the scope.

• Getting the name of the widgets state with runtimeType.toString() also works as expected, but I have also introduced a method to provide a custom name.

I don't think using runtimeType.toString() is viable solution because the class names can be obfuscated. You wouldn't have any way to know what the transaction belongs to. Well, except manually de-obfuscating it without the help of Sentry or the the de-obfuscate tool.

• Also went through flutter docs once more. I don't think we have much else to go by than the post frame callback for stateful widgets. Couldn't even find if post frame callbacks frame of reference is certainly associated with the rendering of the current widget, but it's how this API is used everywhere where I have looked, so I'm assuming this is correct.

The callback is for each frame, so for all widgets which are rendered in that time. So if there are a lot of widgets which use the mixin, you'll have a bunch of transactions which start at nearly the same time and end at the same time. I could imagine that could be a problem. You'll certainly have to really think about when to use it.

I'm not really concerned with widget build/render times because in my experience that's pretty much never the issue. Instead, the issue is mostly in expensive business logic. Dart is single threaded, so business logic can make a frame take a long time. That's why I prefer the idle transaction solution with transaction starting with a navigation event. This is also much more integrated out of the box with the NavigationObserver. If you're also adding frame metrics to the transaction, you also know when there's something wrong.

• There is other API to get durations for frame rendering and rasterisation, so we could observe the performance of the whole application. But it looks like this is not specifically to a widget.

Yep, as seen here.

[denrase]

@ueman Very good feedback, thank you!

• The transaction is bound to the scope, it's wehre we attach the child span from. Issue seems to be that we finish after first render, but child spans run for a longer time? I'm still missing context as to how this is done on other platforms, especially if child spans and http request take longer than the original transaction associated with the screen.
• In most cases rendering would happen in child widgets of that particular screen. The mixing needs to be added manually, so you'd only add it to you "main" navigation screens. But yeah, it's not perfect of course and we don't have render times of individual widgets available to us at runtime, unfortunately.
• Good point with the runtime type & obfuscation, this would not be feasible for the SDK, but it's fine here for testing / dog fooding. 👍

So yeah, all in all, we are not sure if this approach here would provide enough value for users, that's also why we are adding it here and not in the SDK, to see some real-world data and take it from there.