Incorrect event preview shown when filtering by environment

[alyssaruth]

Environment

SaaS (https://sentry.io/)

Version

No response

Steps to Reproduce

1. Set up multiple environments in Sentry, and produce errors in them that will be grouped together as a single issue.
2. From the 'Issues' screen, toggle between the different environments.

Expected Result

The event preview that's displayed under the issue title should update, to show an example relevant to the selected environment.

Actual Result

The event preview does not change. In our case, this often leads to URLs from the dev environment being shown, which is confusing. When you click into the issue, an example from the selected environment is correctly shown - so this only affects the preview.

I've attached screenshots to hopefully show what I mean - the issue shows a CI preview regardless of the chosen environment (but when opened and filtered on production, correctly shows a prod example)

[getsentry-release]

Routing to @getsentry/workflow for triage. ⏲️

[scttcper]

Hey @alyssa-glean filtering by environments currently changes the events graph and displays the events/users count for the selected environment.

The issue title/message will not change by filtering environment as this is how the issue is grouped together. However, the latest event of the issue will reflect the filtered environment when viewing issue details.

[alyssaruth]

Hey @alyssa-glean filtering by environments currently changes the events graph and displays the events/users count for the selected environment.

The issue title/message will not change by filtering environment as this is how the issue is grouped together. However, the latest event of the issue will reflect the filtered environment when viewing issue details.

I think that's fine for the title, because as far as I understand it that will only ever contain information used in the fingerprinting/grouping (such as exception type, the first line of the stack trace and so on). This is information that is totally invariant between environments, because otherwise they wouldn't have been grouped into the same issue.

The message, however, is more problematic IMO. As far as I can tell, the info that ends up in here appears to be drawn from details of the first event that gets seen - in our case, it's often the URL the user was on when the error occurred. This means there's a good chance that it contains environment-specific information. I would argue that this is quite confusing - having filtered only to errors in production, we are faced with messages containing information that's clearly from a test environment. When I first saw this, it made me think that the filter hadn't worked properly and that I was still perhaps seeing problems that weren't relevant to production. Only when clicking into the issue did it become clear that it was in production as well.

From what you've said it sounds like this is just the way Sentry is currently designed, so I suppose this becomes a feature request. Would it be possible to make the message something that's dynamically calculated, rather than statically stored as part of the issue? Or if that would be too slow, perhaps storing a message per environment might be the answer?

[scttcper]

From what you've said it sounds like this is just the way Sentry is currently designed, so I suppose this becomes a feature request. Would it be possible to make the message something that's dynamically calculated, rather than statically stored as part of the issue? Or if that would be too slow, perhaps storing a message per environment might be the answer?

Right, yeah, this becomes more of a feature request. We can look into a per environment message.

What you also might look into is configuring the sdk to make your message generic http://long-url/event/asdf-unique-id might become /event/:id so that its generic between environments and including the actual url as a tag.