Logic Apps: ServiceBus trigger with concurrency control causes peek-lock timeouts

Question

Since a few days I see some "new" behaviour when using the ServiceBus trigger in Logic Apps in combination with the "Concurrency control" feature. I have a polling trigger checking a queue every 5 minutes. And configured the concurrency control to max 5 instances, to not overload my backend database.

In the past when I put 40 messages on the queue, it would spin up 5 instances.. when the polling interval had passed, 3 instances were still running... the trigger then spun up 2 more instances to bring the total running instances back to my configured threshold of 5. I was a happy customer :)

Now I see that the trigger instantly creates 40 instances. 5 of them running, the other 35 in the "waiting" state. When an instance is done processing, one of the waiting instances starts it's work. Sounds good, don't you think? Not in all scenarios..

When using the Peek-lock mechanism the timeout starts counting when the "waiting" instance is started.. If it has to wait longer than 5 minutes (lock timeout max) the lock is expired. This causes the message to become available again on the queue, resulting in a new "waiting" instance being started for the same message. So in the end, I end up with a lot of unnecessary duplicate processing, and even messages being deadlettered because they reached the maxDeliveryCount limit.

Can't seem to find any information on this change in polling behaviour? Anyone with a workaround for the Peek-lock problem besides using Auto-complete?

UPDATE 07/08/2018:

MSFT Logic App Product Team confirmed that this is the new implementation to enable concurrency control for SplitOn triggers. Once you enable SplitOn on your Logic App you will get this behaviour. Even when you disable SplitOn again, the behaviour stays that way. to "reset" your Logic App you will have to completely delete the resource and redeploy it.

Answer 1

MSFT Logic App Product Team confirmed that this is the new implementation to enable concurrency control for SplitOn triggers. Once you enable SplitOn on your Logic App you will get this new behaviour. Even when you disable SplitOn again, the behaviour stays that way. To "reset" your Logic App you will have to completely delete the resource and redeploy it.

If the "waiting runs" implementation suits your scenario, but you still wish to control the number of instances that are started/waiting with each trigger run, there is a setting that you can use to control the maximum “waitingRuns”. Unfortunately, this is not enabled in the UI yet so you need to go to the codeview. At the moment maximumWaitingRuns can't be set lower than 1.