The use case is following:

• whilst processing our pipeline we need to send message (MQ, HTTP, anything else) via asynchronous channel to another system/service
• after that wait until our message get processed by other side and other side send us response/reply
• promote stuck pipeline

The naive approach like:

is obviously broken by design, since other side may reply earlier than camunda have committed process instance state and started waiting for signals/messages. Trying to mitigate such issues on receiver endpoint seems not to be a good idea, because we need somehow distinguish two possible situations:

• we do not see active subscriptions because the process is broken by design
• the pipeline is not actual anymore

The idea of starting waiting for signals/messages prior to sending asynchronous messages:

seems to be more robust, however in my opinion it has two disadvantages:

• due to asynchronous continuation of send message task we have increased latency of our pipeline
• parallel branches of our pipeline are now competing for process instance state in DB, so we do anticipate that process engine may throw OptimisticLockingException in some cases, which, in turn, we would prefer to do not handle explicitly.

So, we came to the following design pattern:

The question(s) is:

• will the last pattern work as expected (i.e. all OptimisticLockingException will be handled by process engine automatically via retry time cycle setting) or we need to replace expanded subprocesses with call activities (I do believe last option should work, however it complicates a lot)?
• how to improve latency of pipeline?