[QUERY] ServiceBusProcessorClient lock expiry

[rileymichael]

Query/Question
Hello! I'm wanting to create a lock expiry monitor for the ServiceBusProcessorClient in PEEK_LOCK mode. I've done a bit of research and was hoping you could point me in the right direction:

• On failed lock refresh (due to network failure for example, within maxAutoLockRenewDuration) and when maxAutoLockRenewDuration has been exhausted, processError is not invoked. This makes sense as processMessage is still running / possibly can't be interrupted. Is there another way to hook into these events?
• Within our processMessage handler, we could check message.message.lockedUntil, which is updated on lock refresh. This only works for non-session processors however, when using sessions messages are locked until +10000-01-01T00:00:00Z (which I'm assuming is because the lock is held for the entire session, even past sessionIdleTimeout). Is there a way of retrieving the actual lockedUntil value?

Why is this not a Bug or a feature Request?
I'm curious about functionality which may already exist.

Setup (please complete the following information if applicable):

• Library/Libraries: com.azure:azure-messaging-servicebus:7.17.2

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

• Query Added
• Setup information Added

[github-actions]

@anuchandy @conniey @lmolkova

[github-actions]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[anuchandy]

Hello @rileymichael, you are correct that for session scenarios, each message does not include the lock timeout, as the lock is scoped to the session.

I'm not exactly sure what the monitoring you mentioned targets, but if it helps, the library emits telemetry for observability purposes - for sessions, there is session lock renew spans and spans for message operations like receiving, completing, or abandoning messages.

[rileymichael]

Thanks for the reply @anuchandy. To be more clear, we want to run some logic in the event a message lock expires before handling has completed (the monitor was just a simple usecase example). We've looked at comparing the current time with the lock expiration time, but as you've confirmed that's not always held by the message. Is it possible to get the session expiration?