Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider all stack traces for grouping #60184

Closed
kerenkhatiwada opened this issue Nov 17, 2023 · 9 comments
Closed

Consider all stack traces for grouping #60184

kerenkhatiwada opened this issue Nov 17, 2023 · 9 comments

Comments

@kerenkhatiwada
Copy link
Member

kerenkhatiwada commented Nov 17, 2023

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
Copy link
Contributor

getsantry bot commented Nov 17, 2023

Assigning to @getsentry/support for routing ⏲️

@getsantry
Copy link
Contributor

getsantry bot commented Nov 17, 2023

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

@getsantry getsantry bot moved this from Waiting for: Support to Waiting for: Product Owner in GitHub Issues with 👀 Nov 17, 2023
@lobsterkatie
Copy link
Member

@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
Copy link
Member Author

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.

@getsantry getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 Nov 17, 2023
@lobsterkatie
Copy link
Member

Thanks for that. And yeah, this is just a slight twist on #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
Copy link

eps1lon commented May 29, 2024

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.

Screenshot 2024-05-29 at 13 21 36
Screenshot 2024-05-29 at 13 21 52

@getsantry getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 May 29, 2024
@JoshFerge
Copy link
Member

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

@AbhiPrasad
Copy link
Member

React 19 concerns fixed with #72593

@lobsterkatie
Copy link
Member

In the case of a chained exception, it turns out we do in fact consider all stacktraces, so I'm going to close this. Please feel free to reopen if there's still a problem.

@github-actions github-actions bot locked and limited conversation to collaborators Dec 26, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Archived in project
Archived in project
Development

No branches or pull requests

6 participants