Regarding accessing sentry with enable and disable switch

[venkat9507]

Future<void> main() async { 

await initializeSentry();

 runApp(MyApp()); 

} 

Future<void> initializeSentry() async {

await SentryFlutter.init( (options) { 

options.dsn = 'YOUR_SENTRY_DSN';
options.tracesSampleRate = 0.1;

  } }

}

Future<void> toggleSentry(bool enable) async { 

if (enable) { 

await initializeSentry(); // Reinitialize Sentry 

} else { 

await Sentry.close();

 }

 }

is this above is possible with sentry do we want to integrate sentry only in main.dart or else in run time we can enable sentry because in official sentry docs they mentioned as in main.dart only so if we enable it in some other place in run time will it cause any issue?

[buenaflor]

The recommendation is to initialize as early in the app's lifecycle as possible.

From the top of my head some instrumentation will be wrong such as app start but for normal error reporting it shouldn't be a problem.

However it is still not a supported use case so we can't make guarantees that it will work flawlessly

If you want to 'disable' and 're-enable' Sentry during runtime I'd rather suggest to use beforeSend where you can manipulate events or drop events based on your conditions

options.beforeSend = (event, hint) {
  // only send events if enabled
  if (enable) {
    return event;
  } else {
    return null;
  }
}

[venkat9507]

you won't recommend enable and disable in runtime instead use before send

Yes. init by itself is not a trivial operation, we do a lot of things so it's not preferrable to toggle it on and off like that anyway.

i'm not sure whether we can use it like that or not

Anything specific why you can't use beforeSend?

If we use beforeSend, it means we are activating Sentry while preventing logs from being sent to the Sentry server, right? So, if we encounter an app crash or any issue, initially, we had enabled Sentry but faced crashes related to it. At that time, we decided to disable it temporarily. Having an option to enable or disable Sentry dynamically would be more effective instead of relying on beforeSend.

[buenaflor]

What kind of crash did you encounter, do you have more infos?

[venkat9507]

What kind of crash did you encounter, do you have more infos?

1. Called sentry multiple times in run time that causes that issue
2. Client side using paid version of sentry at particular time so many errors caught and client want to disable the sentry temporarily but we don't have the option to disable that
3. If we are using beforeSend then we are not sending reports to sentry but we are monitoring and catching it locally right which is seems unnecessary ?

any suggestions ?

[buenaflor]

If we are using beforeSend then we are not sending reports to sentry but we are monitoring and catching it locally right which is seems unnecessary ?

Yeah, it will still continue to monitor.

So in general, running Sentry.init and Sentry.close during runtime can be done and will work for your use case but it may come with side effects such as some data being reported wrong and since these are heavy operations it may also impact performance to some extent. However I'm confident that crashes and errors reported will still be correct so it will work normally for those. But I want to note that this is not an officially supported use-case so we cannot make guarantees here.

Given these trade-offs I'd still suggest using beforeSend but it's up to you.

[venkat9507]

If we are using beforeSend then we are not sending reports to sentry but we are monitoring and catching it locally right which is seems unnecessary ?

Yeah, it will still continue to monitor.

So in general, running Sentry.init and Sentry.close during runtime can be done and will work for your use case but it may come with side effects such as some data being reported wrong and since these are heavy operations it may also impact performance to some extent. However I'm confident that crashes and errors reported will still be correct so it will work normally for those. But I want to note that this is not an officially supported use-case so we cannot make guarantees here.

Given these trade-offs I'd still suggest using beforeSend but it's up to you.

Thanks for the update will get back to you if needed any help regarding this