Slack issue alert links use the wrong environment query parameter

[ricar6os]

Environment

SaaS (https://sentry.io/)

Steps to Reproduce

1. Use an Issue Alert configured for the production environment.
2. Configure Slack as an alert action.
3. Trigger the alert with an event whose environment is production.
4. Open the issue link included in the Slack notification.
5. Check the environment query parameter in the generated URL.

The issue and alert are correctly associated with production.

Expected Result

The issue link generated in the Slack notification should preserve the environment that triggered the alert.

For a production alert, the generated URL should contain:

environment=production

Actual Result

The Slack notification contains an issue link with:

environment=development

even though the alert was triggered by a production event and the alert rule is configured for the production environment.

For example, the generated link uses an environment filter different from the environment that triggered the alert.

As a result, clicking the Slack notification opens Sentry with the wrong environment filter applied.

Product Area

Alerts

Link

No response

DSN

No response

Version

No response

[getsantry]

Assigning to @getsentry/support for routing ⏲️

[linear-code]

ENG-8551

[getsantry]

Routing to @getsentry/product-owners-alerts for triage ⏲️

[Chirag6722]

Had a look at where that query parameter comes from. Traced on a7b4a8a2a78.

The environment on the title link is not taken from the event or from the rule that fired. It is taken from whichever rule happens to be first in the list:

# src/sentry/integrations/slack/message_builder/issues.py:606
key = "legacy_rule_id"
if self.rules:
    key, value = get_rule_or_workflow_id(self.rules[0])
    rule_id = int(value)
    match key:
        case "workflow_id":
            workflow = Workflow.objects.filter(id=rule_id).first()
            rule_environment_id = workflow.environment_id if workflow else None
        case "legacy_rule_id":
            rule = Rule.objects.filter(id=rule_id).first()
            rule_environment_id = rule.environment_id if rule else None

That id becomes the parameter, via get_rule_environment_param_from_rule in integrations/messaging/message_builder.py:106. The same self.rules[0] selection is repeated in notifications/notifications/rules.py:299.

rules is expected to hold more than one. Two places in the same code path say so. In the very same file, the user count deliberately gathers environments from all of them:

# issues.py:76
environment_ids = [rule.environment_id for rule in rules if rule.environment_id is not None]

and the notification renders them as a set: get_rules(self.rules, …) at rules.py:183, which is what produces the "via " list. So when an issue matches a development rule and a production rule, rules[0] picks one arbitrarily and the link advertises that environment regardless of which alert the reader is looking at. That matches the report: a production alert whose link opens environment=development.

The value that would be right is already in scope. Two lines above the rule rendering:

# rules.py:181
environment = self.event.get_tag("environment")

The event that triggered the alert carries its own environment tag, which is what "preserve the environment that triggered the alert" means in the report, and it is already read in that method for other purposes.

The part worth a decision before anyone patches it. Those two are not always the same value, so it is worth saying which one the link should carry:

• the event's environment tag — always matches the event the reader clicked through from, and is defined even when the matched rule has no environment filter;
• the environment of the rule that actually fired — matches the alert's own scope, but needs the notification to know which rule it is for, which is exactly what rules[0] is standing in for today.

They diverge for an all-environments rule: the first gives the event's real environment, the second gives no parameter at all. I would take the event tag and fall back to the rule, but that is a product call about what the link is meant to represent.

Happy to send the patch once you say which. I have read this from source rather than run it, so I have not reproduced the multi-rule case on a live instance — the rules[0] selection and the two multi-rule usages beside it are what I am going on.