The upper-left highlighted task is an external task (just an email sender) and the two others are user tasks, obviously waiting for user interaction.
We wanted to branch out and send emails asynchronously from the rest of the program, so with our current understanding of Camunda we ticked the “Asynchronous Before” box in the service task holding the external topic “SendEmail”.
This has turned out to work kind of the opposite. As seen in the first screenshot from the Cockpit, they all sit and wait instead. And yes we’re run the sanity check that we actually have an external task engine that reads the “SendEmail” topics.
Why is that? What in our understanding is misaligned with Camunda’s reality?
Adding this tick box simply creates a transaction boundary where the engine will commit the state before initializing the external task. This wouldn’t really help what you’re trying to do it. in fact because External tasks already have a transaction boundary by default you’re simply adding an extra step to the execution. Where the engine’s job executor need to query and lock the job before continuing. Take a look at these docs for more details.
Have I just not had a “Job executor” enabled? I don’t have the time to test it right now but that sounds like a reasonable explanation… Not reasonable that it would be disabled, but reasonable cause. We more or less just run a Camunda docker image, which I believe uses an embedded process engine.