Skip reporting blocking calls from the SDK itself

[bruno-garcia]

We have some blocking calls from the SDK which cant' be made async. These are public on the sandbox: https://sandbox.sentry.io/issues/6562584726/?project=4508160335675392&query=is%3Aunresolved&referrer=issue-stream&stream_index=9

They are just wasting quota and are not helpful. We need to build rules to skip reporting these:

See:

• ASPNET Core: Too many blocking calls reported sentry-demos/empower#850

Example:

[jamescrosswell]

@bruno-garcia would this do what you want?

sentry-dotnet/samples/Sentry.Samples.AspNetCore.Mvc/Controllers/HomeController.cs

Lines 45 to 48 in d1e5efc

	using (new SuppressBlockingDetection())
	{
	Task.Delay(10).Wait(); // This is blocking but won't trigger an event, due to suppression
	}

[bruno-garcia]

Possibly, do we need to add this on the background worker?

[jamescrosswell]

Possibly, do we need to add this on the background worker?

I think so yes... it would require suppression to be added to any/all methods that are referencing the _queue (since most of the operations in that _queue are using a lock to ensure thread safety.

We could instead/also refactor ConcurrentQueueLite to use a ReaderWriterLockSlim instead of a lock. I think that would avoid blocking calls on the read operations (like Count, TryPeek and ToArray). From memory, we settled on lock after some benchmarking - although this stuff is happening in a background thread so perhaps we'd rather it be thread pool friendly vs as fast as possible. 🤷🏻

[jamescrosswell]

@bruno-garcia I don't see any blocking calls coming from our SDK when I enable CaptureBlockingCalls in one of the ASP.NET Core sample apps.

However there is a blocking call in the Empower demo when I enable blocking calls for this:
https://github.com/sentry-demos/empower/blob/337053d68aacc7f3cab4a54787524571e8da73a4/aspnetcore/Controllers/ProductsController.cs#L24

So I think the blocking call detection is doing what it should be...

[bruno-garcia]

Another example:

[jamescrosswell]

@bruno-garcia is there any way I can reproduce this? I wasn't able to do so running the ASP.NET server component of the Empower demo locally.

[bruno-garcia]

Based on the stack trace, all you need to do is call CaptureTransaction in the SDK from within a aspnet web request. I think we need the annotation to escape blocking calls inside our CaptureEvent method in the client (or on EnqueueEnvelope on the BG worker)

[jamescrosswell]

That doesn't seem to work.

I'm wondering if the stack trace is off somehow. There are genuinely a bunch of blocking calls in that Empowered demo. I'm wondering if we suppress those, whether you'd stop receiving these blocking call events:

[HttpGet]
    public async Task<IList<Product>> Get()
    {
        var products = await GetProductsAsync();
        
+        using (new SuppressBlockingDetection()) {
-        CallHttpApiAsync().Wait();
+            CallHttpApiAsync().Wait();
+        }
        
        return products;
    }

If so, then it would be a slightly different problem... it would be a mismatched stacktrace problem instead.