ActivitiException: this activity doesn't accaccept signals'

[shrinivas_mujum]

Activiti Error: Signal receive task after a parallel gateway results in "ActivitiException: this activity doesn't accept signals".

Please see the attached process flow diagram.

Consider two workflows after receive task,
Flow 1: ReceiveTask2->ServiceTask2
Flow 2: Call Activiti (this also has a wait task)

Scenarios 1: If Flow 2 completes before Flow 1 then the execution id for ReceiveTask1 and RecieveTask2 are same and via API call we can give signal to this activity. This works as expected.

Scenario 2: If Flow 1 completes before Flow 2 then the execution id for RecieveTask1 and ReceiveTask2 are different and if we try to signal RecieveTask2 via API we end up getting an error "ActivitiException: this activity doesn't accept signals" as the execution ids are different.

Question: We are not able to understand why the execution ids differ in both scenarios? Why it depends on the flow completion? It should be same in both case.


Sorry I am unable to upload Image file for some technical reason.

[frederikherema1]

When a parallel gateway is reached, depending on the number of outgoing flows, there are additional executions created. In some cases, when a child-execution is closed or created, we do some additional magic to reuse/prune execution. If I'm not mistaken, of there is only one child left, it's possible that the last remaining execution (the one holding the signal) is actually replaced by the parent one, having a different execution-id. I can be mistaken, but I know there is some execution-logic related to this kind of use case.

How do you find out the execution-id you need, prior to calling the signal?

[shrinivas_mujum]

So do you want to suggest that, it's a known Activiti issue.

Thanks,
Shriniwas

[frederikherema1]

Again, how do you get the execution-id you want to signal?

[shrinivas_mujum]

When the process is started we store the execution id in database and after parallel gateway we use the same execution id to signal Flow 1 -> ReceiveTask2 (2nd waiting task) as its a same process.

[frederikherema1]

Currently, signaling is done on an execution-level and does not cascade down to child-executions. This is done because it's possible that in a single process-instance, multiple parallel paths are active and contain a receive-task that is waiting for a signal.

I'm afraid you'll have to dig down the execution-tree to find out what execution the receive-task -you're interested in- is waiting in.

[shrinivas_mujum]

Ok. Thanks for the reply.