When enabling attaching the request body Sentry throws endless errors

[Skyppid]

Package

Sentry

.NET Flavor

.NET

.NET Version

8.x

OS

Linux

SDK Version

4.10.2

Self-Hosted Sentry Version

No response

Steps to Reproduce

We have an API which has both a REST API as well as several background processes which work via Kafka or a background services.
In order to better understand issues which are caused by requests from our frontend, we enabled request body capturing. From what I found on the internet this line should be enough to do so:

builder.WebHost.UseSentry(o =>
{
    o.Dsn = "...";
    o.MaxRequestBodySize = RequestSize.Always;
}

Now since we have background processes as well, it seems that Sentry is ignorantly trying to capture the body without checking it's situation. Obviously background services and triggered parts do not have any HttpContext or other features of these. Whenever Sentry tries to create events, it instead fails with the following logs spamming our log files:

[ERROR] | Failed invoking event handler. | System.ObjectDisposedException: IFeatureCollection has been disposed.
Object name: 'Collection'.
at void Microsoft.AspNetCore.Http.Features.FeatureReferences.ThrowContextDisposed()
at void Sentry.AspNetCore.ScopeExtensions.Populate(Scope scope, HttpContext context, SentryAspNetCoreOptions options)
at void Sentry.AspNetCore.SentryMiddleware.PopulateScope(HttpContext context, Scope scope)
at void Sentry.Scope.Evaluate()

Expected Result

No errors from Sentry. If there's noting to capture or no context available it should gracefully ignore that.

Actual Result

Half our logs are Sentry logs telling us that the feature collection was disposed.

[jamescrosswell]

Hi @Skyppid , thanks for getting in touch. Are you able to provide a small app that demonstrates this issue reliably? That would definitely help identify and resolve any problems more quickly.

[bitsandfoxes]

If there's noting to capture or no context available it should gracefully ignore that.

That's the plan!

There are not that many places where we try accessing the context:
We've got the TraceIdentifier

sentry-dotnet/src/Sentry.AspNetCore/ScopeExtensions.cs

Line 36 in c892db4

scope.SetTag(nameof(context.TraceIdentifier), context.TraceIdentifier);

our own ISentryUserFactory

sentry-dotnet/src/Sentry.AspNetCore/ScopeExtensions.cs

Line 44 in c892db4

var userFactory = context.RequestServices?.GetService<ISentryUserFactory>();

and since we don't have SetBody

sentry-dotnet/src/Sentry.AspNetCore/ScopeExtensions.cs

Line 55 in c892db4

SetBody(scope, context, options);

in the stacktrace it's not that or

sentry-dotnet/src/Sentry.AspNetCore/ScopeExtensions.cs

Line 76 in c892db4

var routeData = context.GetRouteData();

either.

Can we check for context.Response.HasStarted to avoid accessing disposed or inaccessible context features?