Errors and not being linked to Spans in traces

[smeubank]

Platform

Flutter Mobile Android

Obfuscation

Disabled

Debug Info

Disabled

Doctor

tbd

Version

latest

Steps to Reproduce

run a hello world flutter app
run the new wizard, enable performance
load app, trigger error when SDK inits or add a bug on some page in your app

Expected Result

There is a span waterfal for the UI page load and errors are linked to it logically

Actual Result

Error(s) appear on a trace, and app span waterfalls appear on different traces

and these traces never have an error in them

Example from a Vue.js application where this is working correctly:

### Tasks
- [ ] If navigation observer is available it controls the trace id generation
- [ ] If navigation observer is not available on mobile should rely on lifecycle hooks to control trace id generation
- [ ] if navigation observer is not available on web, the trace id will stick until refresh

[smeubank]

@denrase and @krystofwoldrich fyi here

from @buenaflor , where he got something semi working locally before PTO:

I only tested some global shared state to check that it does work

What will work right now is this scenario:

• during a transaction if an error happens related to the transaction before it finishes, they will have the same trace id

What should also work if I understand correctly

• during idle transactions (like navigation) if an error happens, maybe even unrelated to the span, they will share the trace id

[denrase]

Think I'm missing context here on how this should behave. I'm just gonna explain the current flow of what we do and then we can maybe see where we need to change.

When a flutter app starts, we fetch the app start data from the native SDKs. We create a root transaction, append all app start date (start, sdk timings, initial display). This is done in NativeAppStartIntegration/NativeAppStartHandler.

We then wait for time to full display, which is called when the apps first widget is build. This finished the root transaction.

Now when an error is triggered later, there is not transactions where we could append it to, as it was already closed.

When I capture an error before calling full display, it has nowhere to be attached to, because we did not bind the root transaction to the scope.

When we do bind the root transaction to the scope and also fix a smaller issue in the navigator observer, we get this result.

So that case would work I guess.

But this still won't resolve the issue if the root screen full display is done and an error happens afterwards, so I'm not sure how to handle this. How do other SDKs do this @krystofwoldrich @stefanosiano ? Do we always have to have a screen/db/http transaction around that's referenced when errors occur?

[denrase]

Oh, and for this to work we have to have the SentryWidget and the SentryNavigatorObserver setup correctly. I think we do add the SentryWidget by default, but we do not add the navigator observer.