Error occurrence count details in filters/discarded-groups/ view
- Dominant language
- Python
- Stars
- 44.8k
- Forks
- 4.9k
- Avg merge
- 21h 10m
- Merged PRs (30d)
- 635
Description
### Problem Statement
Using Sentry for a long time and having accumulated thousands of errors, we have over a hundred "Discarded Issues" (on `/settings/projects//filters/discarded-groups/`). Almost all of these issues were discarded because they were spammy at that time. However, today, many of these are from old releases (which no user is on) or fixed issues (which should not occur anymore), so they cannot spam much.
I would like to prune this list to ensure that any new issue that occurs now and matches one in the list is not discarded (so we can fix it). However, the errors' details are too generic (as previously mentioned in https://github.com/getsentry/sentry/issues/60158). Therefore, I am not so confident in undiscarding them because I am worried about potential spam.
### Solution Brainstorm
The errors are very generic, so it's hard for us to assess whether they're still spammy. If adding all the error details is not feasible, it would at least help to add these two values for each discarded issue:
- date when this issue was discarded
- count of events discarded in the last 30 days due to this issue
Sentry already knows the total discarded count. This count is shown on the same page in a graph titled "Events filtered in the last 30 days (by day)". It would help to see the breakdown of the total discarded count for each of the "Discarded Issues".
### Product Area
Ingestion and Filtering
Contributor guide
Research direction
Start from the discarded-groups view at /settings/projects//filters/discarded-groups/ and trace how its discarded issues and existing 30-day filtered-events graph obtain their data. Determine where the discard date and per-issue event count belong, then verify that the view shows both values for each discarded issue and that the counts cover the last 30 days.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- full-stack
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100