sentry-dotnet icon indicating copy to clipboard operation
sentry-dotnet copied to clipboard

Support Auto Debug Mode

Open vaind opened this issue 1 year ago • 14 comments

This is the current code: https://github.com/getsentry/sentry-dotnet/blob/6274944d00826b0442d038f675f4f46ac0fec182/src/Sentry/SentryOptions.cs#L620-L668

What this effectively does, AFAICT, is that we don't print any warnings when Debug is not set. That is pretty unexpected behavior, at least to me, especially considering what the docs say when you're setting up sentry:

    // When debug is enabled, the Sentry client will emit detailed debugging information to the console.
    // This might be helpful, or might interfere with the normal operation of your application.
    // We enable it here for demonstration purposes when first trying Sentry.
    // You shouldn't do this in your applications unless you're troubleshooting issues with Sentry.
    options.Debug = true;

Instead, I'd expect the DiagnosticLogger property to always be reachable. It already has a check which log levels should be printed.

vaind avatar Mar 12 '24 14:03 vaind

Looks like Debug controls whether the SDK adds its own ConsoleLogger as DiagnosticLogger if none is present. https://github.com/getsentry/sentry-dotnet/blob/dfe208fa3cd51ccdcf0853cbf8b44e2fae2453c3/src/Sentry/SentryOptions.cs#L1636-L1645

Instead, I'd expect the DiagnosticLogger property to always be reachable. It already has a check which log levels should be printed.

You can set your own logger and that works independently whether Debug is enabled or not.

bitsandfoxes avatar Mar 14 '24 13:03 bitsandfoxes

Yes you can. Yet again, shouldn't the default at least print warnings and errors, if any occur? As is, it won't print anything unless you set Debug in which case it will print not only warnings but also all the debug messages.

vaind avatar Mar 14 '24 13:03 vaind

Actually, no, you cannot set a diagnostic logger.

https://github.com/getsentry/sentry-dotnet/blob/6274944d00826b0442d038f675f4f46ac0fec182/src/Sentry/SentryOptions.cs#L651-L653

Can we just remove the need to set Debug for DiagnosticLogger to work at all?

vaind avatar Mar 14 '24 19:03 vaind

Can we just remove the need to set Debug for DiagnosticLogger to work at all?

As in: If there is a DiagnosticLogger present, log?

bitsandfoxes avatar Apr 11 '24 13:04 bitsandfoxes

Yes, pretty much.

vaind avatar Apr 11 '24 14:04 vaind

We could/should be able to control everything via the DiagnosticLevel right? https://github.com/getsentry/sentry-dotnet/blob/0711c17f539a1083ca783555db37368267d32176/src/Sentry/SentryOptions.cs#L641

So SentryOptions.Debug is a bit redundant... although lots of customers will definitely know about it so if we do phase it out, probably need to mark it as Obsolete (and keep it as a proxy to setting the DiagnosticLevel) until some time in the distant future (e.g. v5.0).

Ideally we'd change the default value of SentryOptions.DiagnosticLevel to Warning as well... if people did set Debug = true, that would be (for the time being) an alternative way of setting SentryOptions.DiagnosticLevel = SentryLevel.Debug

jamescrosswell avatar Apr 12 '24 00:04 jamescrosswell

So SentryOptions.Debug is a bit redundant... although lots of customers will definitely know about it so if we do phase it out, probably need to mark it as Obsolete (and keep it as a proxy to setting the DiagnosticLevel) until some time in the distant future (e.g. v5.0).

it is but it's common to all SDKs so I would keep it, just use it to set the diagnostic level to Debug, instead of the default warning - as you're suggesting. The main gripe I have with the current code is the need to enable Debug to get any logs, even warnings

vaind avatar Apr 17 '24 14:04 vaind

The main gripe I have with the current code is the need to enable Debug to get any logs, even warnings

Yeah fair enough. What do you think should happen if people set SentryOptions.Debug = false though (which is the default value for that property)? Would that set the DiagnosticLevel to Error?

If we leave SentryOptions.Debug in the SDK, we have to deal with 10 different combinations of those two settings (Debug x DiagnosticLevel) as well as the order that these are set in (if people are using the Options callback) and which one takes precedence (if people are just passing in an options object). Not saying that can't be done but we'd need to decide how it should work first right?

We could do it a little bit like EnableTracing, which implicitly sets TraceSampleRate to 1.0 or 0.0 depending on whether it's set to true or false. EnableTracing is a bool? though (not a bool). So maybe we could change SentryOptions.Debug to be a bool? and do something similar there? If it's true, we set SentryOptions.DiagnosticLevel to Debug... if it's false we set it to Error... or alternatively people can get more granular by setting SentryOptions.DiagnosticLevel directly. If they've set both though, which one takes precedence?

jamescrosswell avatar Apr 18 '24 08:04 jamescrosswell

I've checked what sentry-java and sentry-dart do and they set the default diagnostic logger if debug is true, otherwise leave a noop logger. I think the idea here was the same (since the .net sdk precedes these two, I think) but somehow the part when a user sets their own logger is messed up here. Maybe we should only fix that instead of touching diagnostic levels.

vaind avatar Apr 18 '24 08:04 vaind