This attempts to simplify the dispatcher a bit where possible to no longer rely on the synchronous path. This PR attempts to find a good balance between allocating the necessary task lists with the number of items needed because that is beneficial compared to doing Task.WhenAll with Select and ToArray
During the discussion with @andreasohlund and @PhilBastian we concluded the original problem would only really have been discovered if the following are true:
Premium namespace (we don't use a premium namespace yet in our CI/CD environment)
The underlying SDK cannot yet have cached the batch size information of the underlying AMQP link (will make the CreateMessageBatchAsync yield) or the large message has to be put into a batch that is sent after the first batch was dispatched
Given that we have not even the premium namespace in place currently, simplifying the dispatcher slightly to avoid such an error seems to be warranted.
I have also removed the yielding, since that was just a way to reproduce the previous problem. With the new structure this is no longer necessary.
Follow through on #1049
This attempts to simplify the dispatcher a bit where possible to no longer rely on the synchronous path. This PR attempts to find a good balance between allocating the necessary task lists with the number of items needed because that is beneficial compared to doing
Task.WhenAllwithSelectandToArrayDuring the discussion with @andreasohlund and @PhilBastian we concluded the original problem would only really have been discovered if the following are true:
CreateMessageBatchAsyncyield) or the large message has to be put into a batch that is sent after the first batch was dispatchedGiven that we have not even the premium namespace in place currently, simplifying the dispatcher slightly to avoid such an error seems to be warranted.
I have also removed the yielding, since that was just a way to reproduce the previous problem. With the new structure this is no longer necessary.