Consider all stack traces for grouping

[kerenkhatiwada]

Problem Statement

At the moment it seems Sentry groups using only one stack trace. This is an issue when there are two stack traces for an issue that are completely different.

Solution Brainstorm

Consider all stack traces for grouping

Product Area

Issues

[getsantry[bot]]

Assigning to @getsentry/support for routing ⏲️

[getsantry[bot]]

Routing to @getsentry/product-owners-issues for triage ⏲️

[lobsterkatie]

@kerenkhatiwada, can you please share some links to events which show this behavior? And when you say "multiple stacktraces," do you mean events with error groups or chained errors, or something else?

[kerenkhatiwada]

Here is an event where we were able to reproduce it. This occurs for javascript error.cause issues. However, AggregateErrors are grouped by all stack traces.

[lobsterkatie]

Thanks for that. And yeah, this is just a slight twist on https://github.com/getsentry/sentry/issues/59679 from earlier this week. As it happens, AggregateErrors aren't grouped on all stacktraces, just potentially more of them than in this case. (See the second example here.) Regardless, we handle this case incorrectly right now.

Question: The current fix for the linked issue is to consider the top error rather than the wrapped one. Would that serve your purposes, or would you actually want both stacks to be included?

[eps1lon]

React 19 will start leveraging the cause property.

Unfortunately, in Sentry, issues are grouped by the actual error message ("There was an error while hydrating but React was able to recover by") not by the cause. I think having the parent as an issue is still nice as an umbrella issue. But the cause should be in a separate issue as well. Ideally with the same trace parent.

[JoshFerge]

thank you @eps1lon -- will get with the team internally and figure out next steps here.

[AbhiPrasad]

React 19 concerns fixed with https://github.com/getsentry/sentry/pull/72593