- Camunda 7.7.2-ee
- Tomcat 8.0.43, shared process engine
I have written a custom ProcessEnginePlugin with a BpmnParseListener and configured in bpm-platform.xml. The plugin does a number of things, one of which is to listen on the User Task TaskListener.EVENTNAME_CREATE event and perform actions. What I’m noticing in my process is that this event does not always fire. See the process below:
Here the user task circled in red is preceded by an External Service Task. The TaskListener.EVENTNAME_CREATE seems to not fire, as it does not invoke the listener code. However, the user task circled in green does get invoked with the TaskListener.EVENTNAME_CREATE event.
More interestingly, if i change the User Task in red to be Asynchronous Before and Exclusive, the TaskListener.EVENTNAME_CREATE now does fire. (The green task is not Asynchronous Before and Exclusive). In both these cases the ASSIGNED and COMPLETE events trigger listener code without issue.
Any insights? Seems odd behavior to me, especially given the Asynchronous Before and Exclusive change and the fact that External Tasks and Human tasks are already wait states.
Let me know what additional information I should provide.
Are you able to reproduce this in a unit test that you could share on github?
Please find the integrations test case here : https://github.com/ajmanlove/camunda-issues . Instructions for running the test are in the repo README.
I’ll be adding another other tests for newly found issues shortly, but for this thread, please only consider the three test cases in
I was unable to reproduce this behavior using a unit test and embedded in memory process engine, however was able to get a simplified reproduction using an integrations test with docker, tomcat, and shared process engine.
Discussed this more with Thorben and Camunda support. Posting back here for community knowledge:
The underlying issue was heterogenous process engine configurations, both in the simulated test case and in our real Camunda cluster. Essentially, the tomcat webapp had the custom plugin enabled, whereas the engine completing the external task (the unit test in the test case and an autonomous java process in our real stack) did not have the plugin enabled. Absent that asynchronous barrier between the external task and the human task, the process engine completing the external task continues until a wait state or asynchronous barrier is reached, in this case after the next user task is created. Given that the custom plugin was not enabled there it obviously couldn’t be invoked.
The issue is solved by enabling the custom plugin on all process engines or by using asynchronous continuations.