Thanks again for the extra information, ideally we shy away from DB manipulation as we also like to air on the side of caution, however, sometimes it is required depending on the nature of the fault.
link is not set to a value error we do actually see this a lot after users upgrade their instances and most of the time a hard refresh of the browser works and it will load the page again, the browser can sometimes cache old pages from the previous upgrade so it may be that a clearing of cache and cookies for the browser does allow you to see the information on that page.
As I was typing I noticed your new comment, it’s good news that the deletion of those 5 deployment records with the null task in them has allowed those releases to load. It seems your issue was related to the second GitHub issue we linked then:
Thank you for investigating that and performing the deletions. Since the task ID for those releases was set to null and not a value this is why you were seeing the other errors too such as
This deployment cannot continue because the variable snapshot associated with it has been deleted error you had in the DB.
As for your tenant concern, I don’t think it seems to be trying to deploy for untenanted and every tenant with no control over what tenant it’s using, although I can see why that GitHub issue would suggest this.
When you tell a project to deploy to tenanted and untenanted it will only deploy to whatever tenant you select for that project. In our documentation on tenanted and untenanted deployments it states:,
If you select an environment that’s when it uses untenanted deployments. So you do have control over what is deployed to where:
I believe this may be addressed in the GitHub issue itself?
Untenanted and tenanted
If the deployment is going to more than one tenant but deployment targets don’t exist for a certain tenant then this will fail.
To avoid releases ending up in this state:
- Switch to a manual deployment phase lifecycle
- Check project tenanted deployment mode settings - if you only need tenanted deployments, don’t select both untenanted and tenanted
I believe this is more related to the environments rather than the tenanted or untenanted, I think the workaround of only selecting tenanted deployments rules out the fact you need to set an environment in the project (which you only do for untentanted).
In the PR for the issue fix our engineers wrote:
If a lifecycle is set to automatically promote a release to an environment, the deployment can fail during its creation. Usually, when this happens via the API we get a response back with the reason why it failed and the entire transaction gets rolled back. For automatic deployments these failed deployments were being partially persisted, meaning the deployment would be left in an invalid state. When opening the release to which this deployment belongs it could cause a React error on the release details page if there was more than one deployment made to the given environment.
So I do think this is more environment-related, it’s just having it set to only tenanted rules out the need to have environments selected, not actual tenants.
I hope that helps alleviate any concerns you may have had, sorry this was a long post but I wanted to try and get all the information to you so you could review it and it would make sense.
Are you happy your project is at a good state now and we can close off this ticket? I will put a link to this ticket on that GitHub issue though, as you are not on a 2022.3 version it would be nice to see if they would include a fix for 2022.2 so I can ask in the GitHub issue. If you subscribe to that you should get notified if our engineers respond.