search

paolosalvatori / ServiceBusExplorer

The Service Bus Explorer allows users to connect to a Service Bus namespace and administer messaging entities in an easy manner. The tool provides advanced features like import/export functionality or the ability to test topic, queues, subscriptions, relay services, notification hubs and events hubs.
MIT License
1.98k stars 577 forks source link

Why is there no "Remove message from queue" when resubmitting a message to a different queue #771

Open dmathijs opened 4 months ago

dmathijs commented 4 months ago

Hi,

We have a use-case in which we have a error and a audit queue next to our regular queue. We would like to be able to re-submit some of the messages from the error queue and delete them (without purging the whole error queue). This possibility exists when resubmitting from a DLQ but not from another regular queue.

Is there a technical reason this was not added? Would you mind if we try adding support for it?

SeanFeldman commented 4 months ago

I don't remember off top of my head, but if you select Repair and Resubmit Message, the popup should have Remove from DLQ. If you do that when resubmitting from an error or audit queue, will it remove the message? If yes, it could be just a naming bug.

ErikMogensen commented 4 months ago

I wrote about it in the PR for that capability, #192 . What may not clear from that text is that all messages in front of the one that you want to delete will have their Delivery count incremented. The default setting is that when the Delivery count reaches 10 the message will be moved to the deadletter subqueue.

That means that suddenly you may end up with messages on the deadletter subqueue.

I think that this capability has been requested for the normal queue once or twice before and it seems to have performed well since it was implemented five years ago. So in my opinion it should be added for normal queues as long as there is a warning that all messages in front of the message(s) that are to be deleted will have their Delivery count increased and that may lead to them being moved to the deadletter subqueue.

SeanFeldman commented 4 months ago

It's already showing on a regular queue as well. that's why I'm confused.

image

So in my opinion it should be added for normal queues as long as there is a warning that all messages in front of the message(s) that are to be deleted will have their Delivery count increased and that may lead to them being moved to the deadletter subqueue.

Now, that is a hazardous thing IMO. Do you happen to remember the details of why a message must be received rather than peeked?

ErikMogensen commented 4 months ago

It's already showing on a regular queue as well. that's why I'm confused.

Yeah, I saw that as well. I think that's a regression issue (since I cannot have create that bug 😄 ).

Do you happen to remember the details of why a message must be received rather than peeked?

Yes, and for that I qoute MikeWo's answer on StackOverflow

The Peek and PeekBatch operations only return the messages and does not lock them at all, even if the receivedMode is set to PeekLock. It's mostly for skimming the queue, but you can't take an action on them. Note the docs for both Abandon and Complete state, "must only be called on a message that has been received by using a receiver operating in Peek-Lock ReceiveMode." It's not clear here, but Peek and PeekBatch operations don't count in this as they don't actually get a receive context. This is why it fails when you attempt to call abandon.

I know I initially tried to use Defer() but couldn't get it to work. MikeWo mentions another Stackoverflow thread where that is mentioned, How to use the MessageReceiver.Receive method by sequenceNumber on ServiceBus. It would be interesting to know it it is possible to use that instead.

SeanFeldman commented 4 months ago

Let's revisit what we do. I just realized that resubmitting a message we receive increases the delivery count. For clients that have MaxDeliveryCount on the entities set to something fairly large, it doesn't pose a problem. But for those who have it set to a relatively small value, risking DLQ messages as a side effect of resubmitting doesn't sit well with me. Let's start from revisiting how the implementation is done.