Significant increasing MessageLockLost error on RenewMessageLock operation.

Question

Significant increasing MessageLockLost error on RenewMessageLock operation.

Junjie Zhang (NCM) 20 Microsoft Employee

Start time: 12/17/2025 04:00 AM (UTC +10:00)

End time: Still ongoing

Our service uses this queue for a long time and recently we find there have significant increasing RenewMessageLock failed errors.

We observed lots of failures trying to renew message, this could be observed from both our service log and Service Bus internal logs.

And we already checked our renew time didn't exceeded the queue's Lock Duration, such for message (tracking id: 33b594d7-172b-43fa-a341-0fd7ebffb25d_B21):

12/19/2025, 2:36:36.719258 AM -- Last round renews message start. 12/19/2025, 2:36:36.766183 AM -- Last round renews message succussed. 12/19/2025, 2:38:59.695319 AM -- Renew message start. 12/19/2025, 2:38:59.695319 AM -- Renew message failed.

Please check the failure reason for the recent message renews.

Error stack (I only post the common error stack and trace id here to avoid any sensitive information):


Azure.Messaging.ServiceBus.ServiceBusException: The lock supplied is invalid. Either the lock expired, or the message has already been removed from the queue. For more information please see https://aka.ms/ServiceBusExceptions . Reference:85b59091-3f5b-421c-8afb-b7c65b7a3dab, TrackingId:33b594d7-172b-43fa-a341-0fd7ebffb25d_B21, SystemTracker:xxx, Timestamp:2025-12-19T02:38:59 (MessageLockLost). For troubleshooting information, see https://aka.ms/azsdk/net/servicebus/exceptions/troubleshoot.
   at Azure.Messaging.ServiceBus.Amqp.AmqpReceiver.<RenewMessageLockInternalAsync>d__65.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Azure.Messaging.ServiceBus.Amqp.AmqpReceiver.<>c.<<RenewMessageLockAsync>b__64_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Azure.Messaging.ServiceBus.ServiceBusRetryPolicy.<RunOperation>d__24`2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Azure.Messaging.ServiceBus.ServiceBusRetryPolicy.<RunOperation>d__24`2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Azure.Messaging.ServiceBus.Amqp.AmqpReceiver.<RenewMessageLockAsync>d__64.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Azure.Messaging.ServiceBus.ServiceBusReceiver.<RenewMessageLockAsync>d__65.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Azure.Messaging.ServiceBus.ServiceBusReceiver.<RenewMessageLockAsync>d__64.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

Siddhesh Desai 5,130 Reputation points Microsoft External Staff Moderator

2025-12-23T13:58:28.7933333+00:00
Hi @Junjie Zhang (NCM)

Thank you for reaching out to Microsoft Q&A

When your code picks up a message from Service Bus, the service locks it for a short time so only your code can process it. If you finish during the lock, you call Complete and the message is removed. If you don’t finish before the lock ends, the lock expires and Service Bus says: “The lock supplied is invalid. Either the Lock expired, or the message was already removed.” This blog says: https://www.tutorialpedia.org/blog/autotmatically-renewing-locks-correctly-on-azure-service-bus/ Keep the lock alive while you’re still working (auto‑renew the lock), and don’t double‑complete the same message.

To auto-renew the lock you need to add below two settings: Lock Duration — configured on the queue/subscription - the time for which your message remains locked for your code to process it. Auto‑renew duration [MaxAutoRenewDuration] — how long the SDK/client/code will keep extending that lock while your handler is running. The limit of Lock Duration on the entity is 1–5 minutes. LockDuration is always less than MaxAutoRenewDuration

You can set LockDuration in Service Bus namespace settings:

And MaxAutoRenewDuration in your code:

Samples below:

C#

var client = new ServiceBusClient("<connection>"); var options = new ServiceBusProcessorOptions {     AutoCompleteMessages = false,     MaxAutoLockRenewalDuration = TimeSpan.FromMinutes(10), // renew up to 10 minutes     MaxConcurrentCalls = 8,     PrefetchCount = 0 }; var processor = client.CreateProcessor("<queue>", options);

Python

from azure.servicebus.aio import ServiceBusClient, AutoLockRenewer client = ServiceBusClient.from_connection_string("<connection>") renewer = AutoLockRenewer(max_lock_renewal_duration=600) # seconds (10 min) async with client:     receiver = client.get_queue_receiver(queue_name="<queue>")     async with receiver:         async for msg in receiver:             renewer.register(receiver, msg) # keeps lock alive while you process             # ... do work ...             await receiver.complete_message(msg)

If you are using Azure Functions you can set it in host.json:

{ "version": "2.0", "extensions": {     "serviceBus": {       "autoCompleteMessages": false,       "maxAutoRenewDuration": "00:10:00",     // renew up to 10 minutes total       "maxConcurrentCalls": 8,       "prefetchCount": 0     } } }

Answer accepted by question author

1 additional answer

Your answer

Answer 1

Hi @Junjie Zhang (NCM) ,

Thanks for reaching out to Microsoft Q&A.

Upon investigating further, the failures occur even though the application’s lock renewal attempts are within the queue’s configured lock duration. The Service Bus namespace is standard, partitioned, and has been consistently healthy. No internal server errors reported before or after the observed increase in errors.

As informed earlier over offline, the RenewMessageLock failures are due to role switches in the partitioned queue, which is a normal behavior in a multi-partition, shared Service Bus namespace.

No action is required from the Service Bus side. Application should ensure robust retry logic for lock renewal failures, as role switches can occasionally invalidate locks.

Hope this helps!

If the resolution was helpful, kindly take a moment to click on and click on Yes for was this answer helpful. And, if you have any further query do let us know.

Answer 2

The MessageLockLost error you are encountering during the RenewMessageLock operation indicates that the lock on the message is no longer valid. This can happen for a few reasons:

Lock Expiration: If the message lock is not renewed before it expires, the Service Bus broker releases the lock, making the message available for other receivers. Ensure that your lock renewals are happening within the lock duration set for the queue.
Message Already Removed: If the message has already been processed and removed from the queue by another receiver, any attempt to renew the lock will fail.
Lock Renew Task: If your application processing time exceeds the configured lock renew task duration, and if the renew task is disabled, this can lead to lock expiration. By default, the lock renew task runs for 5 minutes, but this can be adjusted using ServiceBusReceiverClientBuilder.maxAutoLockRenewDuration(Duration).
Prefetch Feature: If the Prefetch feature is enabled, messages are retrieved and stored in an in-memory buffer without extending their locks. If processing takes too long, the locks may expire while in the prefetch buffer.

To troubleshoot further, you can:

Check the processing time of your messages to ensure they are within the lock duration.
Review the configuration of your lock renew task and consider enabling it if it is currently disabled.
Monitor the usage of the Prefetch feature and adjust it according to your processing needs.

For more detailed troubleshooting, refer to the provided links in the error message for guidance on handling ServiceBusException errors.

Share via

Significant increasing MessageLockLost error on RenewMessageLock operation.

1 additional answer

Your answer