Hello!
I’m hitting an unexpected behavior with Sentry: after I have resolved an issue for a particular error, when a new occurrence of that error comes in it gets bucketed under the resolved issue instead of creating a new issue.
For example, my app hit an error which caused Sentry to create this issue and it initially has been hit once.
Then, I resolve the issue on Sentry.
Next, I trigger the error in my app 2 more times.
EXPECTED: A new Sentry issue gets created and has an event count of 2.
ACTUAL: The existing resolved Sentry issue has an event count of 3:
I see this as a bug or at least unexpected behavior because after I have resolved an issue I am not expecting it to recur and I want to be notified if it does recur. This has repercussions:
- We expected any new occurrences of the issue to alarm our on-call engineer, but they didn’t.
- We expect to see any new occurrences of the issue on Sentry, but we don’t because we filter to show unresolved issues.
We can work around this by “deleting” the issue instead of “resolving” it, but deletion means the issue cannot be found anymore at all and results in broken links. Ideally I would want a new event to cause Sentry to reactivate the resolved issue (and alarm through OpsGenie), or at least to create a new issue.
Can you please confirm the behavior I’m seeing and whether it’s by design?