SentryHttpMessageHandler issue grouping is too eager

[ericsampson]

Problem Statement

When using the SentryHttpMessageHandler, errors from all called URLs get lumped into one Issue. That's not great as the grouping is too eager; it's not very helpful to bundle HTTP errors from 25 different microservices and 15 external SaaS providers into a single Issue.

Solution Brainstorm

I'd love if the grouping could use an auto-parameterized version of the called URL as a grouping key.

[jamescrosswell]

I'd love if the grouping could use an auto-parameterized version of the called URL as a grouping key.

Hey @ericsampson ,

Could you give an example of some URLs that are being grouped together and how these would ideally be grouped instead?

[bitsandfoxes]

We're always looking at ways to improve the out-of-the-box experience. So some examples would be hugely appreciated.

As one way to unblock yourself, you could look into setting your own custom fingerprint for events.

[ericsampson]

@bitsandfoxes re the custom fingerprint option;

• how would I correctly use this with the SentryHttpMessageHandler.cs, i.e. what SentryEvent property should I test against to know in a non-fragile manner that the event source was the SentryHttpMessageHandler ? It sets HttpClientOrigin, but that's an internal prop currently.
• In the custom fingerprint code, would it be correct for me to use the event.Request.Url property?

[ericsampson]

@jamescrosswell unless I'm misreading something in the dashboard, it currently appears that all called URLs are grouped into one single Issue. Because the default grouping that Sentry is choosing for these events is just the stack trace, which is identical regardless of the called URLs.

In my ideal world, each of these lines would be captured as a separate Issue:

GET foo.com/blah
GET bar.org/blah
POST bar.org/blah
// The handler should autodetect that the following called URL pattern is `foo.com/org/{id}/division/{id}`
// via tokenizing the called URL for patterns of `/{number}/?' and `/{UUID}/?` and '/{bool}/?`
// This isn't 100% perfect because it won't catch textual URL path params, but should cover 95% of cases seen in the real world.
GET foo.com/org/1/division/1, foo.com/org/2/division/1, foo.com/org/2/division/2