@Frans Koning
Is there any further information about this issue? Is there a known work-around?
Not a satisfactory workaround in my opinion. See (1) in the comment I posted earlier. This may work around the issue in a development environment but, when using a DevOps pipeline to deploy to a production environment, the behaviour will be lost because the second internal code path will be used.
Earlier post:
Okay, unfortunately this all looks like "by design" behaviour. Apparently there are two internal code paths that determine how waiting runs are handled.
- A workflow is created with a Service Bus peek-lock trigger and no concurrency specified
- After saving, turn on concurrency and save again. Should be no waiting runs
I'm not sure if this behaviour is preserved when deploying to a higher environment in a DevOps pipeline
- A workflow is created with a Service Bus peek-lock trigger and a concurrency value specified
- This will result in waiting runs no matter what is done.