chore(api): Stop calling project-release endpoints #2991
Conversation
### Description We should instead use the organization-release endpoints. The project-release endpoints have been kept around for backwards compatibility with ancient self-hosted versions, which we are dropping support for. ### Issues - Resolves #2840 - Resolves [CLI-186](https://linear.app/getsentry/issue/CLI-186/remove-calls-to-projectsreleases-endpoints)
szokeasaurusrex
force-pushed
the
szokeasaurusrex/no-project-release-endpoint-calls
branch
from
10b34d9 to
ff45453
Compare
![sentry[bot]](https://avatars.githubusercontent.com/u/1396951?s=60&v=4){kind=small}
|
|
||
| /// Returns a list of releases for a given project. This is currently a | ||
| /// capped list by what the server deems an acceptable default limit. | ||
| pub fn list_releases(&self, org: &str, project: Option<&str>) -> ApiResult<Vec<ReleaseInfo>> { | ||
| if let Some(project) = project { | ||
| let path = format!("/projects/{}/{}/releases/", PathArg(org), PathArg(project)); | ||
| self.get(&path)? | ||
| .convert_rnf::<Vec<ReleaseInfo>>(ApiErrorKind::ProjectNotFound) | ||
| } else { | ||
| let path = format!("/organizations/{}/releases/", PathArg(org)); | ||
| self.get(&path)? | ||
| .convert_rnf::<Vec<ReleaseInfo>>(ApiErrorKind::OrganizationNotFound) | ||
| } | ||
| pub fn list_releases(&self, org: &str) -> ApiResult<Vec<ReleaseInfo>> { | ||
| let path = format!("/organizations/{}/releases/", PathArg(org)); | ||
| self.get(&path)? | ||
| .convert_rnf::<Vec<ReleaseInfo>>(ApiErrorKind::OrganizationNotFound) | ||
| } | ||
|
|
||
| /// Looks up a release commits and returns it. If it does not exist `None` |
There was a problem hiding this comment.
Bug: The update_release function incorrectly POSTs to create a new release when release.version is set, instead of PUTting to update an existing one.
Severity: CRITICAL | Confidence: High
🔍 Detailed Analysis
The update_release function incorrectly attempts to create a new release via a POST request when release.version is Some. This occurs because archive.rs and restore.rs callers explicitly set version: Some(version.into()) in the UpdatedRelease struct. The intended behavior for these commands is to update an existing release using a PUT request, which would happen if release.version were None. Consequently, sentry-cli releases archive and sentry-cli releases restore commands will fail or create unintended duplicate releases instead of modifying the status of an existing release.
💡 Suggested Fix
Remove version: Some(version.into()) from the UpdatedRelease struct instantiation in archive.rs and restore.rs to ensure the update_release function performs a PUT request.
🤖 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/api/mod.rs#L541-L550
Potential issue: The `update_release` function incorrectly attempts to create a new
release via a POST request when `release.version` is `Some`. This occurs because
`archive.rs` and `restore.rs` callers explicitly set `version: Some(version.into())` in
the `UpdatedRelease` struct. The intended behavior for these commands is to update an
existing release using a PUT request, which would happen if `release.version` were
`None`. Consequently, `sentry-cli releases archive` and `sentry-cli releases restore`
commands will fail or create unintended duplicate releases instead of modifying the
status of an existing release.
Did we get this right? 👍 / 👎 to inform future reviews.
Reference ID: 3859262
Description
We should instead use the organization-release endpoints. The project-release endpoints have been kept around for backwards compatibility with ancient self-hosted versions, which we are dropping support for.
Issues
projects/{}/{}/releasesendpoints #2840