We are currently using Camunda 7.11.0. All of our workflow tasks are currently async before/after.
We have observed that when we suspend a process definition that it seems to suspend all job definitions for that process definition too as a side-effect (according to Camunda debug logs). This seems to be a good thing to us, since suspending a running process instance invariably ends up with the currently-executing job(s) throwing an optimistic locking exception. But with the job definitions suspended, currently executing jobs can complete but no more can start because all the defs are suspended and no OLEs are seen. Resuming the process definition seems to resume the job definitions as well but not any suspended jobs which resulted from the definition suspension. Those have to be resumed separately (and so far that’s fine by us).
My question is this, though: my internet searches and documentation reading have come up empty on this being documented behavior, so is it something we can count on to continue for future releases?
I don’t know the correct answer to your question, but after a first glance at the
ProcessDefinitionSuspensionTest.java, I found some tests that may fit to the situation you described.
Have a look by yourself here: https://github.com/camunda/camunda-bpm-platform/blob/master/engine/src/test/java/org/camunda/bpm/engine/test/api/repository/ProcessDefinitionSuspensionTest.java.
If you find your situation here, you can be quite sure that the regression is tested every time a new engine is built. If not, you can provide a pull request with this test class and start the discussion with the product team on a concrete proposal.
Hope this helps, Ingo
Thanks for the help. It looks like
testSuspendById_shouldSuspendJobDefinitionAndRetainJob as one example is pretty much confirming what we’ve observed. Though not quite the same as having it in official documentation, I guess we’ll take it as the next best thing.
you can help improving the docs as well. If you click on the small github icon on the top of each page, you get redirected to the source of the documentation.
Here you can edit the page and add relevant content. Once you’ve finished, you can provide your change as pull request in a new branch. The pull request will be verified by the product team and they either propose some changes or accept your pull request.
The complete repository is here: https://github.com/camunda/camunda-docs-manual and the README contains more information, if you want to provide more content.