Issue: Subworkflow is getting triggered twice

[muthurajr]

I'm using v3.0.6 version with postgres as the backend persistence store. Zookeeper based lock is enabled for workflow execution locking with below setting.

conductor.app.workflowExecutionLockEnabled=true
zk.connection=${ZOOKEEPER_CONNECTION:zookeeper:2181}

While trying to execute a workflow which contains subworkflow execution, the subworkflow is triggered twice most of the times and pollCount is displayed as 2. I suspect it might be due to the delay in reading/updating the task through Postgres.

Do we have any property setting or timeouts to resolve the issue? Any help is much appreciated.

[aravindanr]

We suspect that the PostgresQueueDAO might be giving out the message for the SUB_WORKFLOW task twice. Our internal environment uses C* for persistence and Redis for queues. Going through the code, the one (possibly only) way the scenario you described could happen is if the queue gives out the same message twice.

[muthurajr]

I think you are correct. I have noticed the execution twice for SIMPLE & HTTP task types also.

Let me explore whats causing this in PostgresQueueDAO, and in parallel planning to use Redis for Queueing.

[muthurajr]

@aravindanr I have explored little more and this scenario is happening in both postgres and standalone redis. As the subworkflow is triggering 50+ dynamic tasks in parallel, WorkflowRepairService might be requeing the task. For now, I have disabled WorkflowRepairService explicitly using conductor.workflow-repair-service.enabled=false.

[aravindanr]

@muthurajr Thats interesting. Could you tell us if the issue has disappeared after disabling WorkflowRepairService?

[muthurajr]

@aravindanr Yes, the issue has disappeared after disabling WorkflowRepairService