Framework breadcrumbs are not captured in the event

Environment

Using ASP.NET Core 3.1 and Sentry.AspNetCore 3.12.3, sending events to our Sentry SaaS account.

Steps to Reproduce

Send an event to Sentry after having performed an HTTP request with a System.Net.Http.HttpClient, with global default log level of Information and Sentry breadcrumbs enabled at the Information level.

Expected Result

All information logs are included in the event, including the request / response information logs from System.Net.Http.HttpClient (request method / URL, response code).

Actual Result

System.* / Microsoft.* logs appear to be excluded from breadcrumbs. Other information logs are correctly included (application and third party libraries). System.* / Microsoft.* logs are correctly displayed in the console when running locally with the same appsettings.json.

Is this normal behavior (e.g. to avoid overloading the breacrumbs array)? Some of these logs are pretty useful to perform diagnostics.

[madmox]

Making this breaking change would likely have other unintended side effects, such as long trails of breadcrumbs and other events that should have been discarded.

This remark of yours is important in my opinion. If these use cases exist, wouldn’t there be applications where you want both behaviors? i.e. drop undesired events unrelated to the error (I still have to find a use case), and include others (like the HTTP client logs in my client example). It’s the whole “dropping child logging scopes” that I don’t understand and that should be questioned in the first place - I think.

If the behavior has no use case, the boolean parameter approach is good, but it should be set to true by default starting with the next major release and marked as obsolete from there. If this behavior has use cases, I think you might want to consider another approach that allows users more control than a simple on/off switch.

Or maybe the “fix” should be made in .NET and they should stop using nested logging scopes in wrong places, but I doubt that’s the case (I think the primary use case for logging scopes is adding hierarchical metadata to a set of related logs, which could make sense here).

[mattjohnsonpint]

This won’t be a simple fix, as it would require some changes that would significantly change the current behavior. As documented here (emphasis mine):

The scope will hold useful information that should be sent along with the event. For instance contexts or breadcrumbs are stored on the scope. When a scope is pushed, it inherits all data from the parent scope and when it pops all modifications are reverted.

The default SDK integrations will push and pop scopes intelligently. For instance web framework integrations will create and destroy scopes around your routes or controllers.

So, right now everything is working as designed. The problem is that it’s not always obvious that calling a bit of code (like methods on HttpClient) will create and dispose a new logging scope. As a developer, I don’t have a clean way to explicitly opt-in to keep items from child scopes.

FWIW, I tried the following three different approaches for resolving this.

• Attempt 1 copies breadcrumbs from the child scope to the parent scope.
• Attempt 2 uses the existing lock/unlock scope APIs. The net result is that _hub.PushScope doesn’t actually push a new scope but instead applies the state to the current scope. In talking with @bruno-garcia, I’ve come to understand that the whole lock/unlock thing is somewhat of a hack anyway and should probably be removed at some point.
• Attempt 3 completely avoids _hub.PushScope and just makes logger.BeginScope a no-op - effectively just using a single Sentry scope. In doing so, there are three unit tests that break because they were testing the old behavior.

IMHO, none of these is the right approach. Making this breaking change would likely have other unintended side effects, such as long trails of breadcrumbs and other events that should have been discarded.

We need to think through this better, but probably not right at this moment. Will keep it on the backlog for now. Thanks.