Mismatched preview with alert rule behavior when combining environment filters with "when a new issue is created"
- Dominant language
- Python
- Stars
- 44.8k
- Forks
- 4.9k
- Avg merge
- 22h 21m
- Merged PRs (30d)
- 586
Description
### Environment
SaaS (https://sentry.io/)
### Steps to Reproduce
1. Configure an alert for environment A and add "when a new issue is created" in the filters
2. Check preview - issues which have their first event tracked in environment B and later have an event tracked in environment A don't show up
3. Publish alert
Reference: this is the specific set of conditions I had set up, although I believe the noted ones are the only ones which matter

### Expected Result
Alert rule does not fire for issues which have their first event tracked in environment B and later have an event tracked in environment A, as indicated by the preview - OR, preview lists these issues correctly.
I reached out to support and they indicated they believed the alert behavior was correct. Their reasoning was that since there was an environment filter, the alert would fire any time the first event for an issue was tracked in that environment regardless of what other environments it appeared in. I suppose I see the argument, but I was under the impression that "issue" in the Sentry UI essentially always refers to "a collection of events which are referenceable as a single problem" - so if this is intended behavior, I also object to the terminology in the alert condition being "when a new issue is created."
For reference, the alert configuration that was recommended to me was to remove the environment configuration on the alert and instead check the tags, like so:

### Actual Result
Alert rule fires for issues which have their first event tracked in environment B and later have an event tracked in environment A, despite not appearing in the preview.
In particular, an alert was fired for [this event](https://productiv.sentry.io/issues/6211242146/events/179aab5cabe74170b69579db4f99d9ff):

Despite it being initially created in the production environment, and the event in dev did not create a new "issue" (as I understand the word to mean):

And in this case, this issue also doesn't appear in "Preview" when editing the alert rule (you'll have to trust me on this, I don't want to post a screenshot of it - but it doesn't appear in the table at the time that the alert was triggered, at least).
### Product Area
Alerts
### Link
_No response_
### DSN
_No response_
### Version
_No response_
Contributor guide
Research direction
No source files or tests are named. Start by reproducing the environment-filtered alert in the SaaS preview, then compare it with the published alert behavior for an issue first seen in environment B and later seen in environment A; done when the preview and alert behavior agree or the intended condition is clarified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- observability
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100