Skip to content

feat(api): Accept project slugs in release endpoints#117493

Merged
gricha merged 10 commits into
masterfrom
feat/project-id-or-slug-releases
Jun 12, 2026
Merged

feat(api): Accept project slugs in release endpoints#117493
gricha merged 10 commits into
masterfrom
feat/project-id-or-slug-releases

Conversation

@gricha

@gricha gricha commented Jun 12, 2026

Copy link
Copy Markdown
Member

Release threshold create/status endpoints and organization release details now accept project IDs or slugs through the canonical project value while preserving existing projectSlug runtime 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.

@github-actions github-actions Bot added the Scope: Backend Automatically applied to PRs that change backend components label Jun 12, 2026
@gricha gricha marked this pull request as ready for review June 12, 2026 16:23
@gricha gricha requested review from a team as code owners June 12, 2026 16:23
@gricha gricha requested a review from JoshFerge June 12, 2026 16:24
Comment thread src/sentry/api/endpoints/release_thresholds/release_threshold_status_index.py Outdated
@gricha gricha marked this pull request as draft June 12, 2026 18:00
Base automatically changed from feat/project-id-or-slug-resolver to master June 12, 2026 18:50
gricha and others added 5 commits June 12, 2026 11:52
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>
@gricha gricha force-pushed the feat/project-id-or-slug-releases branch from c8dacf0 to 8b486a5 Compare June 12, 2026 18:52
gricha and others added 4 commits June 12, 2026 12:20
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>
@gricha gricha marked this pull request as ready for review June 12, 2026 20:54
# 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")

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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>
@gricha gricha merged commit 19fa980 into master Jun 12, 2026
83 of 84 checks passed
@gricha gricha deleted the feat/project-id-or-slug-releases branch June 12, 2026 22:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Scope: Backend Automatically applied to PRs that change backend components

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants