Ok, I was able to reproduce the OptimisticLock problem by adding flowable:triggerable="true" to my first Service Task.
<serviceTask id="DelegateTest01" name="Delegate 01" flowable:class="com.tests.services.DelegateTest01" flowable:triggerable="true"></serviceTask>
It’s certainly due to the code if(triggerable) {leave(execution);} you mentioned above.
It means that, in a Camel triggerable task (based on a Service Task), the triggerable flag is not ignored 
.
We MUST add the flowable:triggerable="true" attribute if we want to have the same behaviour as the Service triggerable task, meaning no explicit leave(execution) call needed in the trigger method (what makes sense).
And it also means that we really have to be careful about attributes we set (what I can understand) and to know in details how the engine works…
@pstapleton Do you agree with this conclusion?
BTW, isn’t it a possibility to modify the default implementation of CamelBehaviour::execute in order to also manage the triggerable flag?
It would allow to use the default execute (no override so) if we don’t have additional actions in addition to the default Camel route call, and would move the call to leave(execution) in the trigger method if the task is declared triggerable in the BPMN (like for the standard Service Task).
Cheers
William