[grouping] Precedence may be wrong when thread has stacktrace but exception doesn't
- 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`.

(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
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