I just came across this bug after I rebuilt my ant bundle plugin and redeployed it. The server was down when I copied the new ant agent bundle plugin, then I restarted the server and got the attached exception during server startup. I don't know why this happened. But to replicate, you probably need to deploy a ant bundle. I also did some things prior, like deleting bundle deployments, purging deployments, and deleting bundle versions. I don't know if any of that caused this or not. Will attach error.txt.
Created attachment 473452 [details] stacktrace.txt
See this commit, aa3d4cd81b3854ca37f7235103807fedd6bde5d7, which is from the delete-agent-plugin branch and is now in master. Here is the relevant portion from the commit log: Add logic to delete bundles and bundle types ResourceMetadataManagerBean lacks support for deleting content-related stuff. With this commit, it now deletes bundles and bundle types that are associated with the resource type being deleted. I have also added tests to verify that bundles and bundle types are deleted. So with JON 2.4, if you upgrade a bundle plugin, the original bundle and bundle type is not deleted, hence the constraint violation that you are seeing. I am looking at the commit, and we might be able to cherry-pick this over to the release-3.0.0 branch. There are two changes in the commit, both of which are additive. The first is the new code in ResourceMetadataManager bean to perform the deletion. The second is test code in ResourceMetadataManagerBeanTest.groovy which we don't care about.
Upon closer inspection I see that that commit deals with resource type deletion and not with upgrading a resource type. It is/was during type deletion that the bundles and bundle types are not getting deleted. The commit mentioned in the previous comment may not be applicable here after all.
Reproducing this error is straightforward. First deploy a bundle in RHQ. Then deploy an updated version of the ant bundle plugin. Any update will suffice to reproduce the exception. You can do something as simple as changing the version or changing the description. The problem stems from the plugin update code treating bundles the same as content where it is really a special case. When the plugin is updated, we (incorrectly) compare package types and wind up deleting package types which leads to the database constraint violation in the exception. A bundle cannot even declare/have package types, so there is no reason to be comparing and deleting them.
Fix pushed to master. commit hash: 16f1caf77a3f0121530caebb737066191aa87cb3
Bulk closing of BZs that have no target version set, but which are ON_QA for more than a year and thus are in production for a long time.