QueueSource does not remove processed messages from the Azure Storage Queue

[Shawn de Wet]

Version Information
Version of Akka.NET? 1.4.40
Which Akka.NET Modules? Akka.Streams.Azure.StorageQueue

Describe the bug
QueueSource does not remove processed messages from the Azure Storage Queue.

To Reproduce
Steps to reproduce the behavior:

1. Set up an Actor that consumes from an Azure Storage Queue Stream, like so:

protected override void PreStart()
        {
            QueueSource.Create(Queue)
                .RunWith(Sink.ActorRef<QueueMessage>(Self, Done.Instance), Context.Materializer());
        }

2. Let the actor run. Notice how, after the default VisibilityTimeout has elapsed, the Actor receives the Same StorageQueueMessage again.

Links to working reproductions on Github / Gitlab are very much appreciated
I was able to replicate this by modifying the A_QueueSource_should_poll_for_messages_if_the_queue_is_empty test that is found here:
If you modify the QueueCreate instruction to specify a short (5s) VisibilityTimeout, like so:"
var probe = QueueSource.Create(Queue, pollInterval: TimeSpan.FromSeconds(1), options: new GetRequestOptions(TimeSpan.FromSeconds(5)))

Then extend the timeout for which the test Expects No Message, like so:

probe.Request(2)
                .ExpectNext("Test1")
                .ExpectNoMsg(TimeSpan.FromSeconds(10));

Then you see the test failing with the error that a message was found when none was expected. This is because after 5 seconds, the originally processed "Test1" message is now visible again, and then gets returned by the QueueSource again.

Expected behavior
After an Azure Storage Queue message has been delivered to the Sink, it should be removed from the Azure Storage Queue.

Actual behavior
The delivered Azure Storage Queue message remains on the Azure Queue after being delivered to the configured Stream Sink.

Screenshots
None.

Environment
Windows 11 Visual Studio 2022

Additional context
Add any other context about the problem here.

[Shawn de Wet]

I just realized this may be by design?!? In that it should be up to the consumer of the Message (the Actor receiving the message) to remove the message from the Queue after processing it?
In which case, I reckon this becomes more of a request to update the documentation to make this clear. Had me stuck on this for hours.

[Gregorius Soedharmo]

@shawndewet yes, this is by design. The stream itself is not responsible of removing items from the queue, it just reads and emits them as a stream sequentially as it was sent from the server. It does set the item visibility to invisible by the amount of time specified so that it will not be re-emitted before the invisibility timeout expires.

[Gregorius Soedharmo]

We will be adding documentation to the module, sorry for the trouble it caused you.