Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket)
Whenever we have an orphan subscription for a conditional event in the database, and we try to redeploy the same process definition, the deployment succeeds (no exception will be thrown) but we end up with two subscriptions (one for the new deployment and the orphan one), as we can see below:
But only one process definition:
Steps to reproduce (Required on creation)
There's a failing test case in the PR attached to the issue to reproduce easily.
Reach a scenario in which we have an orphan subscription in the DB.
Redeploy the same process definition that the orphan subscription is from.
Check database to see that there's two subscriptions instead of one.
Observed Behavior (Required on creation)
After redeployment, two subscriptions are present in the DB, and one of them is for a non existent process definition.
Expected behavior (Required on creation)
After redeployment we should have only one subscription for the latest definition.
Root Cause (Required on prioritization)
Whenever we deploy a process definition, we remove obsolete subscriptions based on two aspects:
Active subscriptions for formerly latest version.
Subscriptions with the same name as the ones we're deploying and that do not have a related process definition (orphan).
However, conditional subscriptions do not have a name, so they are ignored.
Solution Ideas
We need to change the criteria in which we determine if subscriptions are conflicting and orphan, for example using the configuration column and removing the information about the version before comparing.
Hints
This is happening because conditional subscriptions don't have a name and we're only checking for orphan subscriptions with the same name. We should maybe check for all subscriptions for the given process definition, regardless of whether their names match or not.
Environment (Required on creation)
Any
Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket)
Whenever we have an orphan subscription for a conditional event in the database, and we try to redeploy the same process definition, the deployment succeeds (no exception will be thrown) but we end up with two subscriptions (one for the new deployment and the orphan one), as we can see below:
But only one process definition:
Steps to reproduce (Required on creation)
There's a failing test case in the PR attached to the issue to reproduce easily.
Observed Behavior (Required on creation)
After redeployment, two subscriptions are present in the DB, and one of them is for a non existent process definition.
Expected behavior (Required on creation)
After redeployment we should have only one subscription for the latest definition.
Root Cause (Required on prioritization)
Whenever we deploy a process definition, we remove obsolete subscriptions based on two aspects:
However, conditional subscriptions do not have a name, so they are ignored.
Solution Ideas
configurationcolumn and removing the information about the version before comparing.Hints
Links
Breakdown
Dev2QA handover