[BUG] FluxAutoComplete and FluxAutoLockRenew logic end too early even before the downstream business logic begins.

[michaelqi793]

Describe the bug
FluxAutoComplete and FluxAutoLockRenew logic end too early even before the downstream business logic begins.
Currently, our project need consume service bus messages batch by batch. But the processor client does not support a batch consumer (#23040) . So I turn to ServiceBusReceiverClient, there is a method that returns several messages one time. So I code like this:

 for( ; ; ) {
            IterableStream<ServiceBusReceivedMessage> is = serviceBusReceiverClient.receiveMessages(batchSize);
            List<ServiceBusReceivedMessageContext> li = is.stream().map(ServiceBusMessageContext::new).map(x -> new ServiceBusReceivedMessageContext(receiverClient, x)).collect(Collectors.toList());

            try {
                Thread.sleep(40 * 1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            for (ServiceBusReceivedMessageContext message : li) {
               serviceBusReceiverClient.complete(message.getMessage());
            }

            // my logic to consume the list of ServiceBusReceivedMessageContext
            // .....
}

but when i debug i find the FluxAutoComplete and FluxAutoLockRenew logic will be ended too early even before my logic begins, hence exception raised.

Exception or Stack Trace
....
Caused by: com.azure.core.amqp.exception.AmqpException: The lock supplied is invalid. Either the lock expired, or the message has already been removed from the queue.
....

To Reproduce
Steps to reproduce the behavior:
1 Create a service bus queue and set the Message lock duration to 10 seconds
2 Disable the autocomplete but keep the autolockrenew enabled in the client side
3 Use the code above to reproduce the behavior

Code Snippet
Add the code snippet that causes the issue.

 IterableStream<ServiceBusReceivedMessage> is = serviceBusReceiverClient.receiveMessages(batchSize);
            List<ServiceBusReceivedMessageContext> li = is.stream().map(ServiceBusMessageContext::new).map(x -> new ServiceBusReceivedMessageContext(receiverClient, x)).collect(Collectors.toList());

            try {
                Thread.sleep(40 * 1000); //  Sleep longer than the Message Lock duration set in the azure portal.
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            for (ServiceBusReceivedMessageContext message : li) {
               serviceBusReceiverClient.complete(message.getMessage());
            }
           //  the logic to consume the list/batch of ServiceBusReceivedMessageContext

Expected behavior
A clear and concise description of what you expected to happen.
After the logic consuming the batch of messages ends , the autocomplete and autolockrenew end according to the result of the logic.

Screenshots
If applicable, add screenshots to help explain your problem.

Setup (please complete the following information):

• OS: [e.g. iOS] macOS Big Sur 11.4 other OS may have the same behavior.
• IDE: [e.g. IntelliJ] Intellij
• Library/Libraries: [e.g. com.azure:azure-core:1.16.0 (groupId:artifactId:version)] com.azure:azure-messaging-servicebus:7.2.3

Additional context
Add any other context about the problem here.

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

• [yes ] Bug Description Added
• [ yes] Repro Steps Added
• [ yes] Setup information Added

[ki1729]

@michaelqi793 - Thank you for beinging this up. The way receiver client is designed today, it makes the assumption that there will be no buffering / caching on the downstream business logic. Which is not always true.
There is an active work item to fix this - #26084

The workaround here is to disable AutoComplete and AutoLockRenew on the receiver client by calling ServiceBusCientBuilder.disableAutoComplete() and ServiceBusClientBuilder.setAutoLockRenewaDuration(null).
After disabling, you can call serviceBusReceiverClient.complete(ServiceBusReceivedMessageContext.getMessage()) to complete the message after the downstream logic finishes, and renew message when needed by calling serviceBusReceiverClient.renewMessageLock(ServiceBusReceivedMessageContext.getMessage())

[ghost]

Hi @michaelqi793. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text “/unresolve” to remove the “issue-addressed” label and continue the conversation.