feat(api): Accept project slugs in release endpoints#117493
Merged
Merged
Conversation
Allow release thresholds and release details to resolve project filters by ID or slug while keeping public query parameter docs ID-focused. Co-Authored-By: OpenCode <noreply@opencode.ai>
Document the release details project query parameter as accepting either a project ID or slug and expose it as a string-shaped query value. Co-Authored-By: OpenCode <noreply@opencode.ai>
Use the shared organization helper for legacy projectSlug precedence before release threshold status validation. Co-Authored-By: OpenCode <noreply@opencode.ai>
Use the shared blank-project query cleanup helper before release threshold index validation instead of mutating query params inline. Co-Authored-By: OpenCode <noreply@opencode.ai>
Use the shared integer-or-string schema for the organization release details project filter so generated clients can keep passing numeric project IDs. Co-Authored-By: OpenCode <noreply@opencode.ai>
c8dacf0 to
8b486a5
Compare
Allow explicit project ID and slug sets to flow through project resolution so release threshold status filters do not broaden unexpectedly. Reject the slug for release threshold index filters while preserving numeric all-project sentinel behavior.\n\nCo-Authored-By: OpenCode <noreply@opencode.ai>
Make release project ID-or-slug parsing more explicit while preserving projectSlug precedence and all-project sentinel rejection. Co-Authored-By: OpenCode <noreply@opencode.ai>
Keep the release details project_id query parameter documented and accepted while adding project as the ID-or-slug alias. Co-Authored-By: OpenCode <noreply@opencode.ai>
Keep project_id documented as a deprecated release details filter and point callers to the project ID-or-slug alias. Co-Authored-By: OpenCode <noreply@opencode.ai>
| # Dictionary responsible for storing selected project meta data | ||
| current_project_meta = {} | ||
| project_id = request.GET.get("project") | ||
| project_id = request.GET.get("project") or request.GET.get("project_id") |
Contributor
There was a problem hiding this comment.
Bug: The call to get_filter_params omits the validated project ID, causing get_adjacent_releases_to_current_release to query for releases across all accessible projects instead of the specified one.
Severity: MEDIUM
Suggested Fix
Pass the validated project information to get_filter_params. The call should be updated to self.get_filter_params(request, organization, project_ids=project_ids, project_slugs=project_slugs) where project_ids and project_slugs are derived from the validated project object earlier in the function.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: src/sentry/releases/endpoints/organization_release_details.py#L362
Potential issue: When a `project` or `project_id` is specified in the request, the
endpoint correctly identifies the single project. However, the subsequent call to
`self.get_filter_params(request, organization)` does not pass this project context. As a
result, `filter_params` is populated with all projects the user has access to. This
incorrect set of projects is then used by `get_adjacent_releases_to_current_release`,
causing it to compute adjacent releases across multiple projects instead of being scoped
to the single project from the request parameters. This leads to incorrect next/previous
release navigation on the release details page.
JoshFerge
approved these changes
Jun 12, 2026
Pass the validated release project filter into adjacent release queries so the legacy project_id alias does not broaden next and previous release navigation. Co-Authored-By: OpenCode <noreply@opencode.ai>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Release threshold create/status endpoints and organization release details now accept project IDs or slugs through the canonical
projectvalue while preserving existingprojectSlugruntime and schema compatibility where that parameter already exists. Single-project release detail lookup rejects all-project sentinels and validates project access before filtering.This is the releases split from the project ID-or-slug migration stack and targets the resolver branch so it can be reviewed independently. Validated with focused release endpoint tests, targeted ruff/mypy, and
make test-api-docs.