Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
When mixing Imperative bindings for blob and Declarative bindings for Queue messages, queue messages are written first even when Blob messages are explicitly flushed #1986
I am using a binder to construct the blob name at runtime in my Azure Function. Additionally, I have a queue binding that is declarative. I write to the blob and then flush and close the text writer. Then I add the queue message to the collection. However, the queue message is written before the blob, resulting in the next function in the chain seeing an error.
` using (var writer = await binder.BindAsync(attributes))
I expect the write to the blob to be blocking, and for the queue message to be written after the blob has been written.
The blob messages are not written until the parent function completely finishes execution. While the queue messages are written while the parent function is still running.
Have a copy of the function which processes the SomePoco queue messages, except it accepts input from the poison queue message stream. Then use this to manually clear out poison queue messages.
Provide any related information
I experimented, and it does appear that the binding returned from Binder (e.g. in this case the TextWriter) isn't finalized (the blob isn't written) when the TextWriter is disposed as I had initially thought. The dynamic bindings created by Binder are "finalized" after the function returns, as part of processing the rest of the output bindings. However, the queue message output via AddAsync will be output immediately.
The bindings created via Binder aren't fully flushed until the method returns, as part of processing/finalizing output bindings (see code SetValueAsync).
We need to decide whether this is by design (probably has been this way for years?) or whether we want to provide a Flush API on Binder/IBinder to allow users to force flush.
Thanks! It took a while to figure out that something like that I going on there ;)
Another temporary workaround could be writing to blob storage explicitly, without the