Clarification Needed: Azure Service Bus Message Lock Renewal Behavior

[borbiuk]

I have a question regarding how Wolverine handles message lock renewal when using the Azure Service Bus transport.

In Azure Service Bus (PeekLock mode), message locks are time-limited. For long-running handlers, it’s important to understand:

• Does Wolverine automatically renew message locks?
• If so, what renewal strategy or limits does it follow?
• How does Wolverine behave when handler execution takes significantly longer than the lock duration (e.g., 30–60 minutes)?
• Is there a way to configure a lock-renewal timeout, similar to Azure SDK’s MaxAutoLockRenewalDuration?

At the moment, I haven’t found documentation or configuration options describing this behavior.

It would be very helpful to:

1. Document Wolverine’s current lock-renewal behavior for Azure Service Bus.
2. Clarify whether lock renewal is automatic, configurable, or not supported.
3. (If not currently supported) Consider exposing configuration options to control lock-renewal duration/limits.

Thanks!

[jeremydmiller]

@borbiuk Please don't use GitHub issues for questions. Either try Discord, or Discussions I guess, but we don't check that as often.

No to all your bullet points, it's not something that's really ever come up. But:

• adding the ability to configure the ServiceBusProcessor objects would be a simple pull request
• You could instead use Durable endpoints in Wolverine where the message is ack'd immediately, but tracked in Wolverine's transactional inbox for durability
• I would very strongly recommend against doing a long lived workflow like that anyway and I'd recommend breaking it up into smaller steps anyway -- which is pretty easy to do w/ Wolverine's programming model