Getting too much undiagnosable errors in Sentry for Flutter web

[NicolasDionB]

Problem Statement

Created in part from discussion #1718
We recently set-up Sentry in our project and now that it's in production and used by thousands of people we get a lot of errors and some are not quite useful. By that I mean that we get errors coming from the Flutter SDK or some obscure package. It would be useful if I could disable capturing such errors as I don't have a way to diagnose/fix them. Such an example is:

We use an Azure DevOps git repo. We upload the sources using sentry_dart_plugin, with the following config:

sentry:
  upload_debug_symbols: true
  upload_source_maps: true
  upload_sources: false
  project: live_app
  org: svi-esolutions
  wait_for_processing: false
  log_level: error
  commits: auto
  ignore_missing: true

Finally in my SentryFlutter init, I put the following options:

options.captureFailedRequests = false;
options.enableNativeCrashHandling = false;
options.enableTracing = false;

Solution Brainstorm

Maybe adding an option for this would be great, for instance options.enableSdkErrorCapture which could be disabled by default in my opinion.

Following the same idea, if it is possible, maybe we could have a distinct flag to capture errors coming from dependencies, something like options.enableDependenciesErrorCapture.

Are you willing to submit a PR?

None

[buenaflor]

After taking a look at it, the option inAppExcludes might fit your use case: see here

example : ['sentry'] will exclude exception from package:sentry/sentry.dart

[buenaflor]

Additionally for another alternative you can add stacktrace rules to your sentry project: https://docs.sentry.io/product/data-management-settings/event-grouping/stack-trace-rules/#mark-in-app-frames

so this will also apply to existing events and is not dependent on your SDK options.

[NicolasDionB]

After taking a look at it, the option inAppExcludes might fit your use case: see here

example : ['sentry'] will exclude exception from package:sentry/sentry.dart

Thanks for your ideas! I will have a try but looking at the documentation, for inAppExcludes, wouldn't that only exclude the packages or sdk from the stacktraces and still capture the errors originating from them? If an error occurs in my code and some package has something to do with it, I want to see their code also in my stacktrace. I just don't want exception that are thrown from their code to be captured by Sentry.

For your second comment, I'm not sure how to use that in my case but I will take more time to better understand the approach. But then again, the best solution would be to not capture at all these exceptions in the app, saving a lot of useless process sending them from the clients to Sentry everytime a render error occurs in the Flutter SDK...

[buenaflor]

Okay I now see your problem, it was my misunderstanding.

Just for correctness:

You are receiving unwanted Sentry error events because exceptions are thrown in packages that are not yours or in packages where you don't want to receive errors.

In that case please disregard my previous comment which is not applicable.

By the looks of it these errors are generated by our flutter_error_integration.dart whiuch automatically sends thrown exceptions.

sentry-dart/flutter/lib/src/integrations/flutter_error_integration.dart

Line 101 in 041d84d

FlutterError.onError = _integrationOnError;

So what I can suggest is to override it and only apply it if it matches some condition (for example if the library is only part of the ones you want to report)

Something of that sort:

// onError here is the one overriden by the Sentry integration
final existingOnError = FlutterError.onError;

FlutterError.onError = (FlutterErrorDetails details) {  
  if (librariesYouWantToCapture) {
    existingOnError(details);
  }
};

[NicolasDionB]

Seems a good idea, at least waiting for a real flag in the options of Sentry. Quick question though: how can I filter the libraries exactly? I know there is a "library" property in the FlutterErrorDetails but in my Sentry error report I can't find the value of that so it's hard to predict what I can use exactly to filter. Do you have any recommendation?

[buenaflor]

After investigating a bit this seems to be more difficult than I anticipated. The problem is that it's difficult to differentiate between inApp frames in release mode (obfuscated stacktraces).

What you can do for now is remove the integration like so if you like:

// during init
final errorIntegration = options.integrations.firstWhere(
    (element) => element.toString().contains('FlutterErrorIntegration'));
options.removeIntegration(errorIntegration);

You can also ignore errors directly in the Sentry dashboards but that will still count to your quota so it's not an ideal long term solution for this problem

I'll have to investigate this further if there are reliable ways to filter inApp errors in the SDK

[buenaflor]

@NicolasDionB could you share a link to the issue? if you're not comfortable here you can also send me an email giancarlo.buenaflor@sentry.io

[NicolasDionB]

@buenaflor Sure, here is the link: https://svi-esolutions.sentry.io/issues/4616072482. I also have another similar one that is more bugging me right now: https://svi-esolutions.sentry.io/issues/4619822946. This one has over 20k occurrences, ouch.

[NicolasDionB]

After investigating a bit this seems to be more difficult than I anticipated. The problem is that it's difficult to differentiate between inApp frames in release mode (obfuscated stacktraces).

What you can do for now is remove the integration like so if you like:

// during init
final errorIntegration = options.integrations.firstWhere(
    (element) => element.toString().contains('FlutterErrorIntegration'));
options.removeIntegration(errorIntegration);

...

Would I still capture my inApp errors using your integration removal snippet?

[buenaflor]

@NicolasDionB

Would I still capture my inApp errors using your integration removal snippet?

Unfortunately no, removing it means any unhandled error will not be sent to Sentry which is a risk of course.

Do these errors happen mostly on web or also on other platforms?

[NicolasDionB]

I'm not using other platforms right now, only web for this project. So I will let it activated for now, I hope you can find some way to implement such filtering...

[buenaflor]

You can use inbound filtering which also prevents these events from hitting your quota. Other than that there is unfortunately no reliable way to filter this

[NicolasDionB]

I will check that out right away. I still think an option for this would be much more efficient for anyone wanting to do this, which could be a lot of people using Flutter on the web...

[buenaflor]

Yes, unfortunately though this is a limitation. For example FlutterErrorDetails details: details.library doesn't contain much information, possible values include "gesture" which can also occur inApp. You can filter out if the library is 'Flutter framework' see here but that doesn't filter out everything

For example what we cannot filter at all are errors such as NoSuchMethodError: method not found: 'e' on null which do not have a library since it's not handled by the flutter framework. And the stacktrace is also obfuscated and minified in release so we cannot at all infer where this error occurred, at least not on the SDK side.

Therefore the only real viable solution would be to use an inbound filter.

I will add docs for that in our troubleshooting docs

[buenaflor]

I've opened up a docs pr for this issue.

I'm closing this but feel free to comment if there is anything else you need

[NicolasDionB]

@buenaflor Do you have a link to your doc PR? Maybe that could further help me setting the exception. Thanks!

[NicolasDionB]

Also it seems Custom Error Message filtering is available to Business plans and above only. That's kind of a bummer. Anyway, if the inbound filter works by filtering based on the error message, that's not much help as I can have an legit error such as "NoSuchMethodError: method not found: 'a' on null" coming from my code and not the framework itself. So from what I've seen so far, it is not possible to use Inbound Filtering to filter out errors coming from the framework or a plugin solely based on the error message / title. To me the issue should be reopened, unless I'm misunderstanding filtering 🤔

If we could filter out errors originating from a stacktrace that does not contain any inApp frame that would be a good start. I know dependencies are flagged inApp but a lot of the framework errors are not.

[buenaflor]

Unfortunately there are not many alternatives left, the ones who can work are:

• using inbound filters after the errors are created
• using beforeSend to filter existing errors.

Both of these options only work after the error has been identified.

Unfortunately this is a limitation in the nature of the problem - stacktraces are obfuscated and minified in release mode so there's no way to tell if a frame is inApp until it is unminified and deobfuscated which doesn't happen in the SDK level.

[NicolasDionB]

Ok, I understand. So there is no way of knowing from which package the error comes from until it is unminified and that is done once processed in Sentry, right? That's a shame because those errors cost us money since they are using our quota. Really it would be a must if you could find a way to filter them in the client or using inbound filters to prevent using the quota (re-open the issue maybe?).

But otherwise, is there at least a way to filter them once they are in sentry? I would like to automatically discard or archive (forever) errors that do not contain a single inApp frame in the stacktrace. Any way I could achieve that? Thanks

[NicolasDionB]

@buenaflor I don't know if you saw my previous message but is there a way to automatically discard or archive (forever) errors that do not contain a single inApp frame in the stacktrace? Inbound filtering for that would be great but if at least I can discard them automatically, it's a start!

[buenaflor]

Hey, sorry I missed that

automatic no, you can archive the issue directly but not automatically other than inbound filters.

we are talking with the processing team to check what our options here are.