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.
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?