getsentry / getsentry/sentry

Allow applying several custom fingerprint rules to a single issue

Open
#95,105 4 comments 0 reactions 0 assignees View on GitHub
3. Medium Component: Grouping Feature Product Area: Issues
Dominant language
Python
Stars
44.8k
Forks
4.9k
Avg merge
21h 10m
Merged PRs (30d)
635

Description

### Problem Statement

Sentry allows specifying custom issue grouping rules. However, when an issue matches several rules - only the first one gets applied, afaik. This doesn't work well in a "product teams" scenario.

Imagine 10 teams work on the same Android/iOS codebase. Every team is responsible only for a part of the app's functionality/codebase. There's shared code, which these teams use. The code may eventually report an issue to Sentry. No matter in which part of the app the shared code is used, it produces issue with the same stacktrace and message. To be able to distinct the alerts, produced by different teams (either because of code problem or configuration issue), we introduce a `domain` tag. Different value of this tag means that an issue belongs to different team, even if all other issue metadata is the same. This tag is added to **all** events we send to Sentry.

An issue grouping rule can be easily created to make all issue with different values of the `domain` tag to be treated as unique. However, since `domain` tag is reported in every event we send to Sentry, every issue matches this rule and this makes all other custom rules to not apply.

### Solution Brainstorm

We need some sort of mechanism, which would allow applying multiple grouping rules to the same issue, based on priority. The simplest one is to try to apply all of them starting from top to bottom and don't stop when a rule has already been applied.

### Product Area

Issues

Contributor guide

Open the contributing guide

Research direction

The issue concerns custom issue grouping rules in Sentry's Issues product area, but names no files, tests, or entry points. Start by locating the implementation and tests for custom grouping-rule evaluation. Done means multiple matching rules can be applied in priority order instead of stopping after the first match.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend, observability-sre
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.