receiver.complete_message(msg) is not settling the message in Service Bus Queue

[ravi-stan]

• Package Name: azure-servicebus
• Package Version: 7.12.2
• Operating System: Debian GNU/Linux 12 (bookworm)
• Python Version: 3.9

Describe the bug receiver.complete_message(msg) call is not settling the message in Service Bus Queue, instead the lock is released on the message after completion and the delivery count is incremented and it is available for pickup by next job instance. I have checked the lock_token, _lock_expired & _settled properties pre and post complete_message call, and do not see any anomaly there.

pre complete_message call value of lock_token: xxxx-xxxx-xxxx pre complete_message call value of _lock_expired: False pre complete_message call value of _settled: False

post complete_message call value of lock_token: None post complete_message call value of _lock_expired: False post complete_message call value of _settled: True

To Reproduce Steps to reproduce the behavior:

1. Run the following code from azure.servicebus import ServiceBusClient

import os connstr = os.environ['SERVICE_BUS_CONNECTION_STR'] queue_name = os.environ['SERVICE_BUS_QUEUE_NAME']

with ServiceBusClient.from_connection_string(connstr) as client: with client.get_queue_receiver(queue_name) as receiver: for msg in receiver: print(str(msg)) receiver.complete_message(msg)

2. Look at the message in the queue, it still remains active and available for pickup and delivery count is incremented.

Expected behavior I expect that once the message is settled by complete_message call, it should be removed from the queue.

[kristapratico]

@ravi-stan thanks for your issue, the team will take a look as soon as possible.

[kashifkhan]

Hi @ravi-stan,

I just tried the repro code posted above against a service bus queue with 21 messages. All of them were received by the iterator and then completed with the portal showing 0 messages in the queue after it was done.

My queue was using the default settings. Are there any other details (such as errors) or processes running ?

if you can send DEBUG logs with logging_enable=True we can help you better

import logging
import sys

handler = logging.StreamHandler(stream=sys.stdout)
logger = logging.getLogger('azure.servicebus')
logger.setLevel(logging.DEBUG)
logger.addHandler(handler)

...

from azure.servicebus import ServiceBusClient

client = ServiceBusClient(..., logging_enable=True)

[github-actions[bot]]

Hi @ravi-stan. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[github-actions[bot]]

Hi @ravi-stan, we're sending this friendly reminder because we haven't heard back from you in 7 days. We need more information about this issue to help address it. Please be sure to give us your input. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!

[ravi-stan]

With all the logs enabled I got the following error message on receiver.complete_message(msg) call.

DEBUG | azure.servicebus._pyamqp.aio._transport_async | Transport write failed: ConnectionResetError('Cannot write to closing transport') Transport write failed: ConnectionResetError('Cannot write to closing transport')

[l0lawrence]

Hi @ravi-stan, could you please provide the full logs of the run when the error occurred so we can provide assistance debugging the issue?

[github-actions[bot]]

Hi @ravi-stan. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[github-actions[bot]]

Hi @ravi-stan, we're sending this friendly reminder because we haven't heard back from you in 7 days. We need more information about this issue to help address it. Please be sure to give us your input. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!

[ravi-stan]

Did you try with Message lock duration on queue shorter than the processing time of message, i.e. before the complete_message call?

[kashifkhan]

@ravi-stan just to understand the set up

A queue with a lock time of 5 mins a message is pulled off and then processed for 7 mins then try completing that message?

If thats the case, then the lock has been expired already and is available for someone else to pick up from the queue. That is an expected scenario and things are working just fine. To get around that you would need to use the autolock renewer.

[github-actions[bot]]

Hi @ravi-stan. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[ravi-stan]

@kashifkhan Thanks for your prompt response! Yes, I am using autolock renewer and setting the mac_lock_rnewal_duration as message TLL(which is longer than time it takes to process the message).

[kashifkhan]

@ravi-stan can you provide a repro that shows how you are using the libraries exactly please. It wasn't clear from the initial code that auto lock renewer was being used.

DEBUG logs with frame tracing will also be super helpful. This line shared above would indicate issues on the network side and would prevent a message from being completed

DEBUG | azure.servicebus._pyamqp.aio._transport_async | Transport write failed: ConnectionResetError('Cannot write to closing transport') Transport write failed: ConnectionResetError('Cannot write to closing transport')

however just that one line is not enough for us to make any sort of determination and or have further insights.

[github-actions[bot]]

Hi @ravi-stan. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[github-actions[bot]]

Hi @ravi-stan, we're sending this friendly reminder because we haven't heard back from you in 7 days. We need more information about this issue to help address it. Please be sure to give us your input. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!