It might be related to the Service Bus Processor trying to reconciliate the concurrency together with the prefetch count and that process can take some time.
We have switched to the native way of doing the concurrency and prefetch updates because the SDK already provides such a functionality (and is already in charge of concurrent execution and prefetching). The previous way of starting and stopping the infrastructure had additional overload of having to stop and recreate processors, which also meant more overhead because the underlying connection means had to be re-established by the SDK.
Describe the bug
The following tests behave flaky
When_multiple_messages_are_available_and_concurrency_is_increased_after_pump_startedWhen_multiple_messages_are_available_and_concurrency_is_increased_and_decreased_after_pump_stWhen_multiple_messages_are_available_and_concurrency_is_lowered_after_pump_startedSteps to reproduce
Run the test on the CI build
Relevant log output
No response
Additional Information
It might be related to the Service Bus Processor trying to reconciliate the concurrency together with the prefetch count and that process can take some time.
We have switched to the native way of doing the concurrency and prefetch updates because the SDK already provides such a functionality (and is already in charge of concurrent execution and prefetching). The previous way of starting and stopping the infrastructure had additional overload of having to stop and recreate processors, which also meant more overhead because the underlying connection means had to be re-established by the SDK.