I want my Service Bus triggered Python Azure Function to make the message it has retrieved from the queue available on the queue again to be retried. I want this to happen without having to raise an exception in the function. However as per the documentation:
In non-C# functions, exceptions in the function results in the runtime calls abandonAsync in the background. If no exception occurs, then completeAsync is called in the background.
the completeAsync is going to be called if the function returns successfully.
I am aware that the Service Bus Receiver has a function that allows you to abandon a message so that it is made available on the queue again. But I don't believe this can work in a situation when the Azure Function has already retrieved the message for you.
Also, the ServiceBusMessage object that is received in the Azure function doesn't seem to have a method that lets you 'abandon' or otherwise return the message to the queue.
Most other questions regarding this issue online seem to be specific to C#, so I've not had much look trying to find an answer.
My Azure function is calling a third party API that unfortunately is prone to erroring which is outside of my control. However, when looking at error reports, I don't want this Azure Function to be always be at the top of the list of failing functions. Having to raise an exception in my function when this API call fails seems excessive when it is not an unexpected outcome. I would like to return the function as a success, since from my perspective there is nothing wrong with the function, but the message on the queue needs to be tried again.
The short version is - this can't be done from the Python language worker at this time.
Currently, only the .NET Function workers (both in-proc and isolated) are able to bind to the ServiceBusMessageActions parameter needed to explicitly complete messages. The only way for other language workers to complete a message is for processing to succeed or for it to fail enough times that the delivery count is exceeded or one of the other service-side DLQ actions are triggered and the message is dead-lettered.
Work is planned to bring the message actions functionality to the other language workers but, to my knowledge, there has not yet been a timeline shared.