Can not send message to dead letter queue from new receiver

[ColinBe95]

• Package Name:
  azure-servicebus 7.12.1
  azure-core 1.30.1
  aiohttp 3.9.3
• Package Version:
  7.12.1
• Operating System:
  Windows 10
• Python Version:
  3.9.0
  Describe the bug
  Not sure if this is a bug or desired behavior, but I was very confused by the following:
  When writing a message to the dead letter queue like

from azure.servicebus.aio import ServiceBusReceiver, ServiceBusClient
import os 

connection_string = os.environ["ASB_NAMESPACE_CONNECTION_STRING"]
queue_name = "test-queue"

async with ServiceBusClient.from_connection_string(connection_string) as client:
    async with client.get_queue_receiver(queue_name) as receiver:
        messages = await receiver.receive_messages(max_message_count=1)
        await receiver.dead_letter_message(messages[0])

the message ends up in the DLQ as expected. But when running:

async with ServiceBusClient.from_connection_string(connection_string) as client:
    async with client.get_queue_receiver(queue_name) as receiver:
        messages = await receiver.receive_messages(max_message_count=1)

    async with client.get_queue_receiver(queue_name) as receiver:
        await receiver.dead_letter_message(messages[0])

nothing happens. No error message, nothing. The message does not end up in the DLQ. So basically it seems impossible to add messages to the DLQ once the receiver was closed. Am I missing something?

For my current implementation it would be great if it was possible to send a message to the DLQ even after the receiver was closed.
To Reproduce
Steps to reproduce the behavior:

1. Code examples above are valid and should work

Expected behavior
Sending messages to DLQ after closing the receiver should be possible. Otherwise there should be an exception raised or some information added in the docs.

Screenshots

Additional context

[github-actions]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @EldertGrootenboer.

[kashifkhan]

Thank you for the feedback @ColinBe95. We will investigate and get back to you asap.

[ColinBe95]

btw this behavior is not limited to async, i.e. it is reproducible with the synchronous client. This code snippet works:

from azure.servicebus import ServiceBusClient

connection_string = os.environ["ASB_NAMESPACE_CONNECTION_STRING"]
queue_name = "test-queue"
with ServiceBusClient.from_connection_string(connection_string) as client:
    with client.get_queue_receiver(queue_name) as receiver:
        messages = receiver.receive_messages(max_message_count=1)
        receiver.dead_letter_message(messages[0])

While the following does not:

with ServiceBusClient.from_connection_string(connection_string) as client:
    with client.get_queue_receiver(queue_name) as receiver:
        messages = receiver.receive_messages(max_message_count=1)

    with client.get_queue_receiver(queue_name) as receiver:
        receiver.dead_letter_message(messages[0])

[ColinBe95]

I think I have found the solution to my initial question myself in this discussion Azure/azure-service-bus#455 . However, I still believe raising an exception here would have been a better experience for the developer?

[kashifkhan]

@ColinBe95 yes this is a bug on our end, there should be at the minimum an exception raised or alternate means of sending the message over the dead letter queue. Ill update this thread once we have a PR ready to go

[ColinBe95]

@kashifkhan cool, thank you!

[kashifkhan]

@ColinBe95 I have included a link to the PR that addresses this issue. Ill be marking this issue as addressed but will update here when we push this out to pypi

[github-actions]

Hi @ColinBe95. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text "/unresolve" to remove the "issue-addressed" label and continue the conversation.

[github-actions]

Hi @ColinBe95, since you haven’t asked that we /unresolve the issue, we’ll close this out. If you believe further discussion is needed, please add a comment /unresolve to reopen the issue.