fix(releases): Support environment filter in the query param

[skaasten]

The /releases endpoint returns 400 when the query param contains an environment: token (e.g. ?query=environment:production). Other endpoints accept environment either as a dedicated ?environment= param or inline in the query string; this brings releases in line with that behaviour.

The frontend already sends environment: in the query string for some widgets (e.g. crashes by release), so the 400 is a real user-facing breakage.

What changed

src/sentry/api/release_search.py — added ENVIRONMENT_KEY = "environment" alongside the other local key constants, and included it in the release_search_config allowed-key set so the parser accepts it instead of raising InvalidSearchQuery.

src/sentry/api/endpoints/organization_releases.py — added a handler for ENVIRONMENT_KEY in _filter_releases_by_query. It calls classify_and_format_wildcard() (the same helper used by RELEASE_ALIAS) to map wildcard patterns to the right ORM lookups:

• environment:*foo* → __icontains
• environment:foo* → __istartswith
• environment:*foo → __iendswith
• environment:prod → exact __in
• !environment:*foo* → exclude(...) variant for each

This handles the exact frontend format (!environment:\uF00DContains\uF00Dfoo) that was previously breaking.

Notes

When environment is supplied both as ?environment=prod and as environment:staging in the query string, the two filters are AND-ed — both .filter() calls are applied independently. This is consistent with how other chained filters work and is covered by a test.

release.stage uses filter_params.get("environment") for its environment scoping, which is only populated from the dedicated ?environment= param. This pre-existing inconsistency is out of scope here.

Refs DAIN-1281

[linear-code]

DAIN-1281 Customer unable to create dashboards from widget library

[skaasten]

Migrated these tests to the less verbose style used for other test cases.

[DominikB2014]

I noticed some of the other filter keys do queryset.filter_by_<key> for example queryset.filter_by_semver, should we have filter_by_semver.filter_by_enviornment instead?

[skaasten]

Thanks for the suggestion - I've updated it to now use that pattern. Let me know if that's looking better 🙏

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Autofix Details

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Unconditional distinct() regresses performance-optimized path
  • I replaced the query-time environment filter with an Exists subquery scoped by project and removed the unconditional distinct() so the optimized path no longer pays global DISTINCT overhead.

Or push these changes by commenting:

@cursor push e85c43a17d

Preview (e85c43a17d)

diff --git a/src/sentry/api/endpoints/organization_releases.py b/src/sentry/api/endpoints/organization_releases.py
--- a/src/sentry/api/endpoints/organization_releases.py
+++ b/src/sentry/api/endpoints/organization_releases.py
@@ -5,7 +5,7 @@
 
 import sentry_sdk
 from django.db import IntegrityError
-from django.db.models import F, Q
+from django.db.models import Exists, F, OuterRef, Q
 from drf_spectacular.utils import extend_schema
 from rest_framework.exceptions import ParseError
 from rest_framework.request import Request
@@ -182,32 +182,28 @@
             )
 
         if search_filter.key.name == ENVIRONMENT_KEY:
+            from sentry.models.releaseprojectenvironment import ReleaseProjectEnvironment
+
             negated = search_filter.operator in ("!=", "NOT IN")
             kind, value_o = search_filter.value.classify_and_format_wildcard()
             project_ids = filter_params["project_id"]
+            env_filter: dict[str, object] = {
+                "release": OuterRef("pk"),
+                "project_id__in": project_ids,
+            }
             if kind == "infix":
-                env_q = Q(
-                    releaseprojectenvironment__environment__name__icontains=value_o,
-                    releaseprojectenvironment__project_id__in=project_ids,
-                )
+                env_filter["environment__name__icontains"] = value_o
             elif kind == "prefix":
-                env_q = Q(
-                    releaseprojectenvironment__environment__name__istartswith=value_o,
-                    releaseprojectenvironment__project_id__in=project_ids,
-                )
+                env_filter["environment__name__istartswith"] = value_o
             elif kind == "suffix":
-                env_q = Q(
-                    releaseprojectenvironment__environment__name__iendswith=value_o,
-                    releaseprojectenvironment__project_id__in=project_ids,
-                )
+                env_filter["environment__name__iendswith"] = value_o
             else:
                 env_names = value_o if isinstance(value_o, list) else [value_o]
-                env_q = Q(
-                    releaseprojectenvironment__environment__name__in=env_names,
-                    releaseprojectenvironment__project_id__in=project_ids,
-                )
-            queryset = queryset.exclude(env_q) if negated else queryset.filter(env_q)
+                env_filter["environment__name__in"] = env_names
 
+            env_query = Exists(ReleaseProjectEnvironment.objects.filter(**env_filter))
+            queryset = queryset.exclude(env_query) if negated else queryset.filter(env_query)
+
     return queryset
 
 
@@ -418,7 +414,6 @@
                     status=400,
                 )
 
-        queryset = queryset.distinct()
         queryset = filter_releases_by_projects(queryset, filter_params["project_id"])
 
         if sort == "date":

_{This Bugbot Autofix run was free. To enable autofix for future PRs, go to the Cursor dashboard.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit aa0dc34. Configure here.}

[DominikB2014]

lgtm, one thing we might want to check before is if the query param behaviour matches the beheviour of other endpoints like /events. In particular what happens when we have both the environment query param and envionrment in the query query param

[skaasten]

lgtm, one thing we might want to check before is if the query param behaviour matches the beheviour of other endpoints like /events. In particular what happens when we have both the environment query param and envionrment in the query query param

It appears to me to be the same behaviour (use both) based on here where it applies the query first, and then appends conditions from the separate query params (e.g. environment).