Use different options for native SDK

[Maatteogekko]

Problem Statement

I want to disable captureFailedRequests for the native iOS SDK, but I want to keep it active to make use of the sentry_dio integration. Today the same options are used for the dart SDK as well as the native SDKs, with no easy way to specify different behaviour.

Solution Brainstorm

Allow an optional parameter in Sentry.init to specify options override for a specific integration

Are you willing to submit a PR?

None

[buenaflor]

Hey any specific reason why you want to disable it on native? does it cause duplicate error reports?

[Maatteogekko]

Some native plugins occasionally generate failed network calls, that get reported as issues. I can't do anything to fix or prevent these errors. They are not a problem, but having them in the dashboard adds noise and is inefficient

[buenaflor]

Got it. the first solution would be to disable native init and init the sdks yourselves. That way you have flexibility to disable options to your needs.

Although I do have to say that this method might be overkill for this use case unless you think it is good enough for you.

so I'll get back to you and see what else can be done.

[buenaflor]

What we can do is being able to configure the captureFailedRequest for each integration directly which will take precedence over options.captureFailedRequest. e.g

 // disable in general
options.captureFailedRequest = false;

// and then enable for each integration directly
dio.addSentry(captureFailedRequests: true); 
// or
SentryHttpClient(captureFailedRequests: true);

@Maatteogekko wdyt?

[Maatteogekko]

@buenaflor something like that would work for my use case.

A couple of observations:

1. I don't think there is a case in which one would use dio.addSentry(captureFailedRequests: false);, since the only reason to use dio_sentry is to capture the failed requests.
2. I imagine that there are other cases where one would want to tweak specific settings for a particular integration, apart from captureFailedRequests. I was wondering if a more general approach would be better. Something like dio.addSentry(optionsOverride: (SentryOptions options) {/*return new options*/}) where the options passed in are the ones defined in general. I have no idea if an API like this is feasible though.

[buenaflor]

since the only reason to use dio_sentry is to capture the failed requests.

not quite, the dio integration also features breadcrumbs and performance monitoring.

I'd rather not overcomplicate this and keep it with the added captureFailedRequests parameter for http clients. We can always iterate if we have other use cases.

[Maatteogekko]

Sure, then your proposal works for me. Thanks!

[buenaflor]

@denrase assigning you here, also lmk what you think

[denrase]

@buenaflor I created a small sample with a BeforeInitNativeSDKCallback, where users can mutate the arguments passed to the native SDK. This would provide a mechanism to control all aspects of native SDK initialisation, not just this particular case, but i"m not sure we can be comfortable to directly exposing the arguments.

[denrase]

So for this particular case the setup would look like:

options.captureFailedRequests = true;
options.beforeInitNativeSdk = (arguments) {
  arguments['captureFailedRequests'] = false;
  return arguments;
};

WDYT?

[denrase]

@Maatteogekko We have added additional parameters like suggested by @buenaflor in #1931. It will be part of one of the next releases. Thank you for your feedback!