Manoel Aranda Neto

We've not found the need to do this, the current stable/beta CI builds are working well and we are reacting pretty fast with the breaking changes that are usually landing...

Closing it in favor of https://github.com/getsentry/sentry-dart/issues/1343 Not really the very same thing but the very same symptom. I believe we can address both together.

You can do https://github.com/getsentry/sentry-dart/issues/711#issuecomment-1106119591 or https://github.com/getsentry/sentry-dart/blob/fa16e53b4bb6d070a637610acb48612b82700d3c/dart/lib/src/scope.dart#L211-L213

Background isolates might help solving this issue, if we are able to offload to a background Isolate and this Isolate is able to call method channels, only possible on Flutter...

We can actually do this with `integration_test.dart` and do something similar to `e2e_test.dart` so we know that the generated file is also valid and accepted by Relay.

I think we could do this similar to RN, which is calling Sentry's API and waiting for the response, and asserting that the data sent is actually what we're expecting....

Right now this runs only on Android and iOS emulators, let's try to make it platform agnostic, also running on Desktop/Web, or do that later on in a different PR....

A downside of this is when apps are obfuscated (Web is minified), or AOT via https://docs.flutter.dev/deployment/obfuscate The `inApp` detection is always setting all the frames to `false`.

@ueman fair point but we always forward the call to the default handler https://github.com/getsentry/sentry-dart/blob/d235a79dc30772bb861de3eec8222cf2300bbd23/flutter/lib/src/integrations/flutter_error_integration.dart#L90-L92

So the problem here is not the `FlutterErrorIntegration` but rather the `RunZonedGuardedIntegration` which is responsible for capturing the errors shown in the issue description. We do log the error tho,...