getsentry / getsentry/sentry

[grouping] Precedence may be wrong when thread has stacktrace but exception doesn't

Open
#94,820 0 comments 0 reactions 0 assignees View on GitHub
Improvement
Dominant language
Python
Stars
44.8k
Forks
4.9k
Avg merge
21h 10m
Merged PRs (30d)
635

Description

A customer is ending up with things being overgrouped because we're grouping on a generic error message from `exception` rather than the stacktrace in `threads`.

![Image](https://github.com/user-attachments/assets/5b439fe2-3e67-4475-b235-58abc0e43c06)

(Note that there are some questionable in-app rules being applied there - every one of those is a known system frame - but for the purposes of this issue all that matters is there are frames which we would use if we weren't ignoring the thread outright.)

We should see about marking the exception component as non-contributing in this situation. (We'll need to figure out if that's always the right thing first.)

Contributor guide

Open the contributing guide

Research direction

Trace the grouping logic for events where `threads` contains a stacktrace but `exception` has only a generic message. Determine whether the exception component should be marked non-contributing in this case, including whether that rule is always valid; done means the grouping behavior is corrected and the relevant regression coverage passes.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
observability-sre
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.