enableDuplicateFiltering is not working - fix and potential bug

Original post.

After spending a LOT of time on this issue, my colleagues and I were finally able to figure out what the problem was.

When we call deploymentBuilder.deploy(), org.camunda.bpm.engine.impl.cmd.DeployCmd.execute(commandContext) is invoked. If you follow the chain of execution, you will find that Camunda first attempts to load any existing resources to compare with the new resources that are being deployed. It does this lookup on the basis on deployment name, resource name, source and tenant ID.

Keep following the execution and you will see that the query that is eventually invoked to lookup existing resources, goes by the key “selectLatestResourcesByDeploymentName”. And therein lies the problem. We were not setting a name (or source) value for any of our deployments. As such, all records in the ACT_RE_DEPLOYMENT table had null values for name and source.

This “selectLatestResourcesByDeploymentName” query fails to find any existing deployments/resources if the name of the new deployment being passed in is null. BUT, if we do set a name on all of our deployments, then the lookup succeeds, existing resources (if any) are loaded, and a byte comparison is done between the new and existing resources to determine if there was any change between them. Since the existing resources always returned an empty list, all our resources were being deployed on every restart of the application.

I don’t know if this is as designed or if this is a bug. Either way, there should be something in the Camunda API documentation to indicate that deployment name should always be set. We were operating under the assumption that setting the tenant ID on the deployments would be sufficient but clearly the lookup fails without the deployment name.

The logical thing, IMHO, is that if there is no name set on the new deployment, then the “selectLatestResourcesByDeploymentName” query should return all existing deployments/resources where the deployment name is null.

So, ultimately it was a simple fix. Just set a name on all your deployments (deploymentBuilder.name(“name”)). As for us, we chose to set the name with the same value as our tenant ID.

1 Like