Improve log output during SDK init

[markushi]

Description

io.sentry.android.core.LoadClass.loadClass spits out an exception to the log output if a certain class is not available (androidx libs, Jetpack Compose) - this can be quite confusing for anyone using our SDK.

Fixes getsentry/sentry-dart#2824 (comment)

[feinstein]

There are so many logs, including some about serialisation and installed modules. Honestly this all seems like debug info that's helpful to you, but should be silent for the end user.

I would recommend that you put all those logs behind a flag, so they can enabled when you are developing the sdks.

[markushi]

@feinstein just to clarify: You seem to have SDK logging enabled at the debug level for your builds, so it's expected to be quite verbose. See https://docs.sentry.io/platforms/dart/guides/flutter/configuration/options/#debug for more details.

[feinstein]

Ok, but I think there's a difference between the debugs logs that are useful for devs and the logs that are useful to the SDK development. I feel that the logs are just too verbose to the point where they are useful for SDK development, not the users. And this being true by default when we run in debug (which is what everyone does during development) will just flood everyone's terminal during development.

[adinauer]

@feinstein the diagnosticLevel option defaults to DEBUG, have you tried setting a different level?

[feinstein]

I will try, but that's not my point, I mean that these shouldn't be the default levels as I believe it's too noisy for everyone that's not working in the SDK development, or correct me if I am wrong please.

[adinauer]

We use the debug log for supporting customers as well. It's easier to simply tell customers to set debug=true and then by default we get logs that actually help locate any problems.

[stefanosiano]

hi @feinstein
I get your point. For flutter specifically, v9 will raise the default log level to warning.
This is a point to consider for Java/Android, as well

[feinstein]

Thanks @stefanosiano. I did a test here and setup my level to warning and I got these logs when I Hot Restarted my app:

D/Sentry ( 5032): Failed to delete: /data/user/0/uk.co.goshorty.goshorty.stg/cache/sentry/5b38cfeb18a05f1ef09960dd9b32f3dac5c1d97b/.options-cache/proguard-uuid.json
D/Sentry ( 5032): Failed to delete: /data/user/0/uk.co.goshorty.goshorty.stg/cache/sentry/5b38cfeb18a05f1ef09960dd9b32f3dac5c1d97b/.options-cache/dist.json
D/Sentry ( 5032): Failed to delete: /data/user/0/uk.co.goshorty.goshorty.stg/cache/sentry/5b38cfeb18a05f1ef09960dd9b32f3dac5c1d97b/.options-cache/replay-error-sample-rate.json
D/Sentry ( 5032): Failed to delete: /data/user/0/uk.co.goshorty.goshorty.stg/cache/sentry/5b38cfeb18a05f1ef09960dd9b32f3dac5c1d97b/.scope-cache/user.json
D/Sentry ( 5032): Failed to delete: /data/user/0/uk.co.goshorty.goshorty.stg/cache/sentry/5b38cfeb18a05f1ef09960dd9b32f3dac5c1d97b/.scope-cache/level.json
D/Sentry ( 5032): Failed to delete: /data/user/0/uk.co.goshorty.goshorty.stg/cache/sentry/5b38cfeb18a05f1ef09960dd9b32f3dac5c1d97b/.scope-cache/request.json
D/Sentry ( 5032): Failed to delete: /data/user/0/uk.co.goshorty.goshorty.stg/cache/sentry/5b38cfeb18a05f1ef09960dd9b32f3dac5c1d97b/.scope-cache/fingerprint.json
D/Sentry ( 5032): Failed to delete: /data/user/0/uk.co.goshorty.goshorty.stg/cache/sentry/5b38cfeb18a05f1ef09960dd9b32f3dac5c1d97b/.scope-cache/contexts.json
D/Sentry ( 5032): Failed to delete: /data/user/0/uk.co.goshorty.goshorty.stg/cache/sentry/5b38cfeb18a05f1ef09960dd9b32f3dac5c1d97b/.scope-cache/extras.json
D/Sentry ( 5032): Failed to delete: /data/user/0/uk.co.goshorty.goshorty.stg/cache/sentry/5b38cfeb18a05f1ef09960dd9b32f3dac5c1d97b/.scope-cache/tags.json
D/Sentry ( 5032): Failed to delete: /data/user/0/uk.co.goshorty.goshorty.stg/cache/sentry/5b38cfeb18a05f1ef09960dd9b32f3dac5c1d97b/.scope-cache/transaction.json
W/Sentry ( 5032): Current session is not ended, we'd need to end it.

It's way better than what I was getting before, but still, is this expected to happen at each hot restart?

[romtsn]

@feinstein Yes this is expected (those files probably don't exist, or not modifable during a hot-reload phase).

[feinstein]

Then why are they being logged as warning, if they are expected to happen?

[romtsn]

Good point, we'll get this checked and change the level. Thanks!

[buenaflor]

I assume this also fixes this right? getsentry/sentry-dart#2673

cc @markushi