azure-service-bus
azure-service-bus copied to clipboard
Azure
ReceiveAsync By SequenceNumber is not supported in .net core for Azure Service Bus Subscriptions
Issue Transfer
This issue has been transferred from the Azure SDK for .NET repository, #15097.
Please be aware that @evhfla is the author of the original issue and include them for any questions or replies.
Details
Library or service name. Microsoft.Azure.ServiceBus
Is your feature request related to a problem? Please describe. Need the ability to receive a specific message for a subscriber of a Topic by sequencenumber. It is supported in the full .net sdk, but not supported in the .net core sdk. The .net core sdk only supports PeekBySequenceNumberAsync, which doesn't acquire a lock and therefore, you can't complete that message.
Original Discussion
@jsquire commented on Fri Sep 11 2020
Thank you for your feedback. Tagging and routing to the team best able to assist.
@msftbot[bot] commented on Fri Sep 11 2020
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @jfggdl, @axisc.
@jsquire commented on Fri Sep 11 2020
//cc: @JoshLove-msft, @MiYanni
@SeanFeldman commented on Fri Sep 11 2020
Note that this method was also "lost" in track 1 SDK while available in track 0.
@SeanFeldman commented on Fri Sep 11 2020
Track 0 overload that takes sequenceNumber is here.
@axisc commented on Fri Sep 18 2020
Discussed this with @SeanFeldman offline. While the functionality to receive with a sequence number isn't intuitive for a Queue or Subscription, it's adds value when peeking/receiving from a deadletter entity.
@evhfla did you have other scenarios in mind? Receiving from a standard queue/subscription with a sequence number is like querying a database so it's a less preferred pattern with queueing where the default should be FIFO.
@evhfla commented on Fri Sep 18 2020
No, I only need it for the deadletter queue, as I want to give users the ability to choose which messages in the deadletter they want to retry, edit and retry, or just delete without retrying.
@axisc commented on Tue Sep 22 2020
@evhfla, @SeanFeldman this feature was removed due to lack of support from the AMQP protocol (in track 0 it was implemented using SBMP).
Since the use-case is for DLQs only, we will investigate internally and identify a possible solution or workaround.
@SeanFeldman commented on Tue Sep 29 2020
Since the use-case is for DLQs only, we will investigate internally and identify a possible solution or workaround.
Coincidentally, I have an example where this assumption does not hold true. A customer had a logical error and has sent messages with future enqueue date/time. Those messages need to be "patched". The process would include "receive by sequence number and replace with a correct message" for all messages that are impacted and scheduled. But at this point, it's not possible other than going with the old track 0 SDK. And this is not a DLQ, so the assumption is inaccurate, @axisc.
@ErikMogensen commented on Thu Jan 07 2021
I am pretty sure ReceiveAsync(Int64) in track 0 only is able to receive deferred messages and the documentation should be updated. The ability to receive normal messages was something that I and others asked for a lot some years ago. Clemens was involved in at least one of the discussions.
Since it was important to be able to remove deadletter messages without having to start with the top one I implemented a nasty workaround for Service Bus Explorer where it peek-locks and abandons every message until it gets to the message which is to be removed. Since this increments the Delivery count for the messages that are older than the intended one, I only implemented this for the deadletter subqueue.
So it would be great if this was implemented.
@paolosalvatori commented on Fri Jan 08 2021
In the past, I submitted internal feedback several times and asked for the possibility to extend the possibility to receive messages from a queue or subscription by sequence number beyond deferred messages. In fact, this functionality is required to properly implement Message Repair and Resubmit pattern in the Service Bus Explorer tool (Im' the owner of the tool, @SeanFeldman and @ErikMogensen are co-owners).
@aguetat commented on Wed Feb 17 2021
@ErikMogensen could you share your solution plz (even if it's a bad workaround)
@ErikMogensen commented on Wed Feb 17 2021
Sure @aguetat. It is in https://github.com/paolosalvatori/ServiceBusExplorer/blob/develop/src/Common/Helpers/DeadLetterMessageHandler.cs.
@awseeley commented on Wed Mar 31 2021
I would also like the ability to be able to query the queue SequenceNumber. Our main scenario in particular is to be able to "fix" a particular message (E.g. if the body is incorrect for a downstream application).
The only workaround for this is to receive all messages until we get a match on the sequence number/message-id then take action to send the message back to the queue for processing. (As per @ErikMogensen 's workaround)
( I am using the azure-sdk-for-js which also has this limitation)
@ramya-rao-a commented on Tue Aug 24 2021
@shankarsama, This feature would first need to be implemented in the service side. Can you please transfer/move this issue to the https://github.com/Azure/azure-service-bus repo where you collect feature requests for the service?
@SeanFeldman commented on Sun Oct 31 2021
@kevinlam1 would it be possible to nudge internal folks? Got to admit that it's quite frustrating to see issues like this where broken internal communication is exposed.
@SeanFeldman commented on Sun Oct 31 2021
@jsquire, do you not have the right to transfer the issue? And if you don't, could you raise a new one (I've seen folks doing that on behalf of the users raising issues in the .NET SDKs repo) rather than just backlogging? I understand that it's not your job to chaise the messaging team and ensure they raise the issues. However, it would be helpful if issues don't just get buried in the backlog here but surface up. I appreciate your help.
@jsquire commented on Mon Nov 01 2021
Hi @SeanFeldman. Thanks for the ping; the backlog assignment was part of a triage script that identified this issue because tagging was changed to a feature-request which requires a milestone. This is the first time that I've looked in on this since the initial triage.
I just caught up on the thread; I'm not sure why the transfer wasn't performed when it was identified as needed, but I'll take care of it now.
We don't want to break queue principles so we won't implement this on the main entities, but it is something we can consider for the DLQ. We have added an investigation item to the backlog.
I'm splitting a specific use case to cancel scheduled messages into a feature request - https://github.com/Azure/azure-service-bus/issues/659. I can support not breaking the queue semantics with arbitrary message receiving by sequence number, but cancelling a scheduled message is a different beast.
Thank you for your feedback on this item, it helps us in our efforts to continuously prioritize the different requests we get from all our various feedback channels. We have added this feature in our backlog, however we currently don't have an ETA on when development might start on this. For now, to help us give this the right priority, it would be helpful to see others vote and support this feature, as well as explain their scenarios.