Documentation issue - advise that assembly names that start with "Sentry" won't have their logger entries logged

[getsentry]

Documentation issue - advise that assembly names that start with "Sentry" won't have their logger entries logged

[bruno-garcia]

I'm sorry that wasted your time.
I hope it's clear why we filter out Sentry namespace though since this avoids an internal error in the SDK getting into an infinite loop.

Besides documenting this behavior, I'd also suggest we log a debug message.
This way, for those who didn't spot the note in the docs, by enabling Debug mode it will be clear what's going on.

Thanks for raising this.

[cpwood]

Just wondering whether there's potentially another way forward.. Thinking out loud here.

Is it true to say that any Sentry namespaces that could cause infinite loops are either within the Extensions.Logging project itself or a referenced assembly? If so, I'm just wondering whether you could say "it begins with Sentry and it's in this assembly or one of this assembly's references".

[bruno-garcia]

An error could come from Sentry package and end up in a global handler defined by the application which calls LogError. Or from a package that wraps MEL like Sentry.AspNetCore.

We could have this filter prefix configurable, with Sentry there by default.

At least this is only an issue when creating test apps named 'SentryTest' or something.

Perhaps a simple fix would be to simply changing to:

namespace.StartsWith("Sentry.") || namespace == "Sentry"

This could be a simpler change.

[bruno-garcia]

@cpwood I was explicit about this behaviour in the docs now:

https://docs.sentry.io/platforms/dotnet/microsoft-extensions-logging/?platform=aspnetcore#installation