azure-service-bus
azure-service-bus copied to clipboard
Azure
Bug: Auto-forwarded messages exceeding max number of hops end up in DLQ and not TDLQ
Description
According to documentation, auto-forwarded messages exceeding max number of hops should end up in TDLQ. This is not what's happening.
~~Also, auto-forwarding of these messages from DLQ to a centralized queue is broken as well. So it's a 2 bugs in 1 😃~~ Replaced with #249
Actual Behavior
Message ends up in DLQ
Expected Behavior
Message should go to TDLQ and if not, auto-forwarding to another queue should be respected.
Looks like we may need to update the document instead. I also created a new issue for creating a send via sample: #50
@binzywu so you're saying rather than being moved to the TDLQ is should be moved to the normal DLQ?
@sethmanheim thank you. Even though it would be much better to see PG have some discussion/collaboration on this issue rather than internal bug tracker only, it's better than nothing.
Seem's this issue still exists. When forwardDeadLetteredMessagesTo is enabled on a subscription and maximum number of (system) hops is exceeded, messages are moved the dead-letter queue of the last subscription. There they are basically inaccessible due to the following exception, which is raised the trying to receive from the subscriptions dlq (not the auto-forwarding target):
InnerException: Cannot create a message receiver on an entity with auto-forwarding enabled. TrackingId:7574a23c-9353-4a5c-9752-79d5692d2ebf_G45_B39, SystemTracker:mysb:Topic:input|sub|$DeadLetterQueue, Timestamp:2022-07-06T06:38:15
We have opened an investigation task for this in our backlog, and will update this issue when we have more information.
We have updated the documentation with the correct behavior, which can be found at https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dead-letter-queues#dead-lettering-in-auto-forward-scenarios.