[BUG] Service Bus retry functionality not working as expected

[ragnaroh-nrk]

Describe the bug
When a message is received from an Azure Service Bus queue, and the message processing fails, the message is retried immediately instead of waiting for the configured delay. This seems like a bug to me, unless there's something I'm missing. No matter what I set as retry mode or delay, (and no matter if I configure the retry properties under spring.cloud.azure, spring.cloud.azure.servicebus or spring.cloud.azure.servicebus.processor) failed messages are retried immediately.

Exception or Stack Trace
Log output:

2025-01-20T12:56:08.974+01:00  INFO 83782 --- [azure-service-bus-retry-issue] [ receiverPump-2] com.example.MessageDemo                  : Message received: Hello, World!
2025-01-20T12:56:08.975+01:00 ERROR 83782 --- [azure-service-bus-retry-issue] [ receiverPump-2] com.example.MessageDemo                  : Error when processing message: Simulated error
2025-01-20T12:56:09.022+01:00  INFO 83782 --- [azure-service-bus-retry-issue] [ receiverPump-2] com.example.MessageDemo                  : Message received: Hello, World!
2025-01-20T12:56:09.022+01:00 ERROR 83782 --- [azure-service-bus-retry-issue] [ receiverPump-2] com.example.MessageDemo                  : Error when processing message: Simulated error
2025-01-20T12:56:09.029+01:00  INFO 83782 --- [azure-service-bus-retry-issue] [ receiverPump-2] com.example.MessageDemo                  : Message received: Hello, World!
2025-01-20T12:56:09.029+01:00 ERROR 83782 --- [azure-service-bus-retry-issue] [ receiverPump-2] com.example.MessageDemo                  : Error when processing message: Simulated error
2025-01-20T12:56:09.035+01:00  INFO 83782 --- [azure-service-bus-retry-issue] [ receiverPump-2] com.example.MessageDemo                  : Message received: Hello, World!
2025-01-20T12:56:09.035+01:00 ERROR 83782 --- [azure-service-bus-retry-issue] [ receiverPump-2] com.example.MessageDemo                  : Error when processing message: Simulated error

(and 6 more retries)

To Reproduce
See this demo repo: https://github.com/ragnaroh-nrk/azure-service-bus-retry-issue

Expected behavior
I expect the message to be retried after the configured delay.

Setup (please complete the following information):

• OS: iOS
• IDE: IntelliJ
• Library/Libraries: com.azure.spring:spring-cloud-azure-starter-servicebus:5.19.0
• Java version: 21
• App Server/Environment: Tomcat
• Frameworks: Spring Boot

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

• Bug Description Added
• Repro Steps 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 @ragnaroh-nrk, thanks for reaching out. This is expected and by design. The scope of the retry configurations are applied solely for internal transient errors, such as network errors occurring on the connection between the broker (Service Bus) and client. The library will report user-thrown errors to the user's error handler but will not make any decisions based on such external errors.

[ragnaroh-nrk]

Hi @anuchandy. I see. Thank you for your response. I guess I can achieve what I want by disabling auto-complete (through spring.cloud.azure.servicebus.processor.auto-complete), and relying on the Message lock duration and Max delivery count (configured through Azure Portal), by letting the lock duration expire upon application-specific transient errors.

[anuchandy]

Hi @ragnaroh-nrk, right, If the application does not complete the message (say message-a) within its locked period, the broker will make message-a available again for reading once that time expires. Note that, when the application returns control from the handler without completing or abandoning message-a, and if a new message (say message-b) is available in the queue, message-b will be immediately delivered to the handler.

[ragnaroh-nrk]

Thanks again! Feel free to close this issue

[anuchandy]

Closing the issue.