When using a retry policy with a service bus trigger, the retry loop should be cancelled if the lock is lost. If the retry loop is not cancelled, this will lead to duplicate message processing, and the retry will fail because the instance no longer has the lock. This may also cause the retry loop to continue (because the retry failed) but I haven't verified.
Unlike the eventhubs issue, there is much less reason to use a retry policy with service bus, as it has built in retry support. However, there is no enforcement that prevents a retry policy from being applied. So this issue could be resolved in one of two ways - cancelling the retry loop as discussed, or fully blocking the use of retry policies for servicebus triggered functions. If we do neither of these, I suspect this behavior will be a support case generator.
This is the service bus version of this issue: https://github.com/Azure/azure-functions-eventhubs-extension/issues/92
When using a retry policy with a service bus trigger, the retry loop should be cancelled if the lock is lost. If the retry loop is not cancelled, this will lead to duplicate message processing, and the retry will fail because the instance no longer has the lock. This may also cause the retry loop to continue (because the retry failed) but I haven't verified.
Unlike the eventhubs issue, there is much less reason to use a retry policy with service bus, as it has built in retry support. However, there is no enforcement that prevents a retry policy from being applied. So this issue could be resolved in one of two ways - cancelling the retry loop as discussed, or fully blocking the use of retry policies for servicebus triggered functions. If we do neither of these, I suspect this behavior will be a support case generator.