Cancel the pipeline execution when the lock is lost

[danielmarbach]

This PR leverages the feature that I contributed to the client library. The client library has the possibility to subscribe to message lock lost events. When the message lock is lost, the message becomes available for consumption again

When a message is locked, other clients receiving from the same queue or subscription can take on locks and retrieve the next available messages not under active lock. When the lock on a message is explicitly released or when the lock expires, the message is placed at or near the front of the retrieval order for redelivery.

and attempts to settle the message will fail. See

The Complete, DeadLetter, or RenewLock operations might fail due to network issues, if the held lock has expired, or there are other service-side conditions that prevent settlement. In one of the latter cases, the service sends a negative acknowledgment that surfaces as an exception in the API clients. If the reason is a broken network connection, the lock is dropped since Service Bus doesn't support recovery of existing AMQP links on a different connection.

If Complete fails, which occurs typically at the very end of message handling and in some cases after minutes of processing work, the receiving application can decide whether to preserve the state of the work and ignore the same message when it's delivered a second time, or whether to toss out the work result and retries as the message is redelivered.

the same applies for Abandon

The lock for the message has expired or the message has already been completed. This does not apply for session-enabled entities. The Reason will be set to MessageLockLost in this case.

While this mechanism only applies for the PeekLock Mode the client will simply not raise those events in the Receive-And-Delete mode.

By triggering the cancellation token that is eventually passed into Core when the message lock is lost this gives the clients that are forwarding the token the opportunity to abort their processing logic earlier since any attempts to eventually complete the message would throw a lock lost and the message would be retried anyway.

[danielmarbach]

Marking it temporarily as a draft since there are a few edge cases that might need some more thinking

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.