Sentry: Can't delete release due to "active" issues which have been deleted

[adamreisnz]

I'm trying to delete a release using the CLI but it's telling me that:

This release is referenced by active issues and cannot be removed

There was one active issue for that release, which I removed through the UI. However, it's still not allowing me to delete the release.

I have double checked in the UI to make sure there are no other issues attached to that release but the UI reports 0 issues and filtering on the release finds nothing.

Is this a bug where an issue needs to be resolved before it's deleted or do we need to wait a certain amount of time before the issue is actually removed from the server and the release can be deleted?

[adamreisnz]

For reference, the related issue has ID 307955667 and when I browse to it again the UI says The issue you were looking for was not found..

[adamreisnz]

Looks like it was a timing issue. I've tried again now, and it managed to delete now.
Is there some kind of delete cycle that cleans up deleted issues every few hours only?

Perhaps the error message should be updated to clarify this.

[dcramer]

I think that maybe we should just remove the constraint on first_release_id, and handle that failure gracefully. It's silly that you cant remove this data, and while I still stand by the reason why (its core metadata, and usually you shouldnt need to remove it), its also not that big of a deal/

@tkaemming thoughts?

[adamreisnz]

Any update?

[dcramer]

Just so this doesn't go stale, we dont consider this a high priority. Generally releases are expected to be important metadata that should rarely be deleted.

[rmacklin]

I had the same issue today. It wasn't a huge deal because I was able to just wait and eventually the deletion succeeded, but figured I'd confirm that it doesn't seem to let you delete the release right away (as in shortly after you've deleted the active events for that release).

[dcramer]

@rmacklin can you explain why you are deleting releases?

They're not really intended to be deleted, especially not on a regular cadence. The deletion is more about "I need to remove this because there's something sensitive or completely broken", and we've had discussions internally about preventing the removal of releases. The primary issue here is once you have issues associated with a release it makes no sense to actually remove the release sense it breaks chains of metadata.

[rmacklin]

@dcramer, sure.

First, I'm definitely not currently deleting releases on a regular cadence (nor do I plan to). The releases I've deleted have never been "real" releases. I was experimenting with the "associate commits with a release" API and I created some test releases in the process. Once I got a handle on the different parameters for this API, I deleted these releases. There was also a brief period when I was initially adding Sentry to my project where I had put release: TODO as a placeholder to remind me to come back and add the code for actually getting the correct release value after I had tested that my basic Sentry setup was working. So the TODO release was another one that I deleted, and unlike the others, this was the only one that actually had active issues which led to me posting on this issue.

Without the ability to delete releases, I could have accomplished this by creating a separate "test" project in Sentry and using that project's DSN while I was experimenting, before switching to the real project's DSN. However, at the time, I didn't have permissions to create a new project under my organization, so to avoid being blocked by that permissions issue, I used the real project's DSN to avoid being blocked (and that did allow me to experiment much faster).

[zuibunan]

@dcramer
I have a lot of experimental releases cannot be deleted !

[buildqa]

I don't see I have any active issues with some test releases I made (that I would like to now delete). I can delete the tag associated with any release via, e.g.,
$ hub release delete
$ github-release delete -u -r -t

• but these commands do not delete the files in the release. If you run the commands a second time they report they cannot find the release with that tag (as the tag is now gone). So GitHub is setup so that you can delete the tag for a release but you can never actually delete the files (build artifacts) in the release associated with a now non-existent tag from the command line? It seems reasonable to expect to be able to remove the files as well as part of a build/test/release cycle.

[buildqa]

I should have written something like "github-release delete -u userid -r reponame -t tag name"

[TheCodeKing]

I have the same issue. I created a new project but it's picked up a release used in old project with same name, and I can't delete it. It says release is referenced by active issues and cannot be removed. There are no issues visible in the UI or CLI for me to delete.

[doudounannan]

I have the same issue.

[iegik]

Clear all filters, and delete all issues!

[markstory]

'Active issues' is determined by any issues having a first_release_id that links to the release being targeted with a delete. If you're using onpremise you can find those events by searching through the sentry_groupedmessage table using first_release_id column.

[jfcere]

Like @adamreisnz commented, I came back the day after deleting all issues linked to the release I wanted to delete and I've been able to remove it.

[StinsonZhao]

The same problem.

So I need to wait for maybe a day to delete unused releases?

PS. I use onpremise to host sentry on my own server.

[BYK]

@markstory can we not migrate this data to another release? Alternatively, we can soft-delete relaeses, which we'd essentially hide but keep in the data-store for integrity reasons?

[markstory]

@BYK Both are doable. Soft-deleting creates more complexity down the road for us as there isn't generally much data that we use soft-deletes on. Using a celery task to null out the first_release_id of the affected groups, and putting the release into a 'pending-delete' state is more consistent with how other resources behave.

[dcramer]

There’s no value in migrating data. We could just make release metadata immutable and remove the idea that you can delete them. The identifier isn’t getting cleared from events after all.

You’d still need to be able to prune files and commits likely. We could also make it so you can hide releases.

Either way probably something we need to do here since this comes up frequently enough.

[BYK]

There’s no value in migrating data. We could just make release metadata immutable and remove the idea that you can delete them. The identifier isn’t getting cleared from events after all.

This probably wouldn't solve the issue as it is mostly "I want to get rid of all erronous/test release ids". If they keep showing there, I'm sure it will keep annoying people. It was annoying to me when I was testing stuff.

[dcramer]

What if instead, we do this..

• Deleting a release sets Release.status = PENDING_DELETION (similar to other systems)
• It gets enqueued to run async, and will retry with delay until Group.first_release_id no longer references. This job would use the same checks as other deletes, so if Release.status = ACTIVE it aborts.
• At points where a release would get created (event pipeline, API) the release is not ACTIVE, it gets restored.

[dcramer]

Alternative plan..

• Deleting a release sets Release.status = PENDING_DELETION (similar to other systems)
• It gets enqueued to run async. This job would use the same checks as other deletes, so if Release.status = ACTIVE it aborts.
• It iterates through each matching first_release and "fixes" it (it bumps it to the next release that has been seen by the Group?). This means it doesnt block on Issue deletion.
• At points where a release would get created (event pipeline, API) the release is not ACTIVE, it gets restored.

[mlcohen]

I'm running into the same problem. I've created test releases that I wish to delete but am unable to do so because the release still reference "active issues" even though the project the release is associated no longer has any active issues listed (all the issues generated were for testing the sentry platform).

As a solution, why not allow an API/command call that allows a release to be deleted under a forced condition. If the idea of "forcing" deletion seems highly risky, then it could be protected under a restricted permission set against a user account. The permission can, say, only be assigned by someone with an administrator role. Would that work?

[mscalzotto]

Same issue here. I've a release that has an active issue and was resolved. When I delete the issue in the UI there's a legend saying "This issue has been marked to be deleted" or something related. After that, There're no visible issues in the release, anyway, the release cannot be deleted as it says that "This release is referenced by active issues and cannot be removed".

[mscalzotto]

Forget my previous comment. Finally, I could delete the issue some minutes later.

[LiShuxue]

I am facing the same issue, i delete the issue but not resolve it, then when i delete the release, it show me "This release is referenced by active issues and cannot be removed", i don't know how to delete the release, i already wait some minutes, but still can't delete it

[LiShuxue]

I delete the release successful, after 1 hour later.
Suggest change the error message , to let customer know they can delete , but need time.

[AvailCat]

For release still referenced in first_release_id and don't want delete issues:

• You must have permission to shell into the environment that run sentry.
• Tested on 9.1.2
• Backup data so you won't be fired

select * from sentry_release WHERE version = 'v1.2.3;

And got:

| id | project_id | version |
| ---- | ----------- | -------- |
| 114 | | v1.2.3

Then check is this error caused by this release still referenced in first_release_id

SELECT * FROM sentry_groupedmessage WHERE first_release_id = 114;

If any data, run

UPDATE sentry_groupedmessage SET first_release_id = 113 WHERE first_release_id = 114;

Note: Replace 113 with an older release id, i don't know what will happen if you set it to a release that does not exists.

Then try delete again in dashboard, it should success if there isn't any issues linked to it.

[jingzhiMo]

Maybe in the same sentry organization, other project have some not resolved issue that related same release name. For example:

project Foo and Bar are in same sentry organization sentryOrg. Foo and Bar have same release name v1.0.0.

project Foo
 --v1.0.0
    -- issue-1
    -- issue-2

project Bar
 --v1.0.0
    -- issue-3
    -- issue-4

If you clear Foo issue and then delete release v1.0.0, maybe it is not work. Because Bar have some issue in v1.0.0. Foo and Bar are in same sentry organization sentryOrg.