Bug with Releases API? - Creating Release with same ID in Two Projects Causes Issues

1

TL;DR - If you create a release in one project with a certain ID, a call to create a release with the same ID in a second project returns the first project from the original API request.

Background

We bumped into an odd issue these last few weeks. During our staging release we create a release in our staging Sentry project with a Git SHA as the release ID, and then upload the assets and sourcemaps. Then when we promote that container to production we do the same thing with our production Sentry project. I started noticing odd errors when uploading sourcemaps in production of ‘file with this name already exists’ but it would upload anyway…

Here’s a gist of an example script to recreate the issue and the output I see (view the original as there are two files):

Things to note:

  • In step 3) I create the stage release on project kindness/kindness-frontend-staging with the release ID ‘luke-test-release’. The JSON response has a dateStarted of “2017-01-25T15:35:28Z”, which is the same as the end of the step 3) line.
  • In step 4), I create the production release on project kindness/kindness-frontend with the same release ID ‘luke-test-release’. The JSON response has the same dateStarted as the staging release, even though it should have the dateStarted at the end of the step 4) line, “2017-01-25T15:35:35Z”, which makes me think its return the wrong one
  • In step 6) I upload a test file to the production release with the same name as the one on the staging release. The response JSON complains that the file already exists for this release, put it uploads the file anyway

If I change the release name so its different in each project, e.g. ‘staging-luke-test-release’ it works as expected.

Have I missed something in the docs that says Releases are not scoped by project? Or is this unintended behaviour?

Thanks
Luke

1 Like
2

Aha, so you’re hitting us right in the middle of transitioning. Releases used to be scoped per project, but they’ve been moved up to per-organization. But the old API end points work. They just translate back to creating per-organization level releases. The product will become more clear relatively soon why we’re doing this. But yes, your suspicions are correct. Within an organization, you should name them uniquely moving forward or we assume they’re the same.

1 Like
3

Okay cool, thanks for the quick reply. I’ll change the release IDs to be unique per project. Might be worth add a note to the docs in the meantime unless its imminent so no-one else is caught out!

4

Could you add this somewhere in the docs? We use different Sentry projects for different staging/int/prod environments and use git hashs to identify releases. I can see this being a major head scratcher for a lot of teams that attempt the same approach.

1 Like
5

@matt I agree with @codeocelot this has to be there in the docs, I spent an entire day figuring out this :unamused: