Unrelated errors are grouped together

[aludvigsen]

Is there an existing issue for this?

• [x] I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• [x] I have reviewed the documentation https://docs.sentry.io/
• [x] I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/nextjs

SDK Version

9.x

Framework Version

Next 15.3.2, TRPC 11.1

Link to Sentry event

No response

Reproduction Example/SDK Setup

I upgraded from version 7 to version 9, and after the upgrade a lot of my errors are grouped together even though they are not related except they all are "TRPCError"s.

Steps to Reproduce

Triggering an error in different trpc procedures.

Expected Result

Triggering an error from different procedures should result in a separate issue per error.

Actual Result

Errors ends up in the same issue on Sentry with the title and message from the initial error shown on top.

[andreiborza]

Hi @aludvigsen, thanks for filing this. We briefly discussed this on discord where I suggested trying to downgrade to 9.19.0 (version before we added isolation scope forking for the tRPC middleware) but that did not alleviate the issue.

in v9.19 it differentiates queries and mutations, but different mutation endpoints (trpc-endpoints) still get merged together.

[chargome]

Hey @aludvigsen would you mind pasting a link to two of these events that should not be grouped together? 🙏

[aludvigsen]

Here is an example with two sample events.

[chargome]

I'm assuming they are grouped together because of the matching stacktrace. I'll check that with our issues team and get back to you 👍

[chargome]

@aludvigsen grouping kicks in due to the exact same stack trace. There is an argument for grouping these as they are both zod validation errors though. What would be the optimal solution here for you, having each validation error reported separately based on the exception value?

[aludvigsen]

Thanks for checking @chargome! In a way, that makes sense—both are Zod validation errors. However, I think the reason the grouping feels off is because the errors come from different API endpoints (trpc endpoints in this case), which makes them feel like two distinct and unrelated issues to me. They’re triggered in separate parts of the code, so it’s not a single error to fix, but two. On top of that, the second error is somewhat hidden, since the message/title shown on the Sentry issue page is based on the first error.

edit: Another small pain point is that after I fix one error and mark the issue as resolved, I’ll get a regression alert later if a new, unrelated validation error occurs.

[chargome]

@aludvigsen yeah would make sense in this case to not group them. Could you provide a small reproduction on that so we can look into it in detail?

[aludvigsen]

@chargome I created a minimal reproduction here

[chargome]

@aludvigsen thank you so much, we'll take a look 👍

[Lms24]

I have an update on this issue after looking into the reproduction:

• The stack traces from the two errors are indeed (almost) identical even though they're originating in two different TRPC routes. My best guess is that TRPC handles input validation internally before going down any route path and hence the traces are identical. That being said, I know nothing about TRPC internals, this is just intuition.
• Ideally, we can make our grouping algorithm smart enough to group TRPCErrors based on stack trace and contexts.trpc.procedure_path (which maps to firstEndpoint and secondEndpoint in the provided repro).
• I'm not sure yet whether we should change this SDK-side or we can adjust the algorithm. Will ask issues/grouping folks to chime in with ideas.

[Lms24]

In any case, I'd rather re-classify this as an improvement than a bug because it's not per sé wrong behaviour, based on our overall strategy of grouping on stack traces.