1

I am trying to trigger an azure function on a change in cosmos db using the cosmos db changefeed. I am trying to trigger the function "at-least-once" using the available retry-policies: https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-error-pages?tabs=csharp

So, I have an azure-function triggered by a CosmosDbTrigger, which has no built-in resilience. I have declared an infinite retry-policy on this azure-function to remedy this. If the function fails for any reason, the retry-policy works as expected, and the function is rerun after a fixed delay. I can also verify that my lease-item in cosmosdb does not update as long as the function does not return a successful result. However, as soon as I stop my azure function and start it again, the function is not retried anymore. The lease has been updated and my only interpretation of this is that the checkpoint in the cosmos db has been advanced. (The behaviour is the same if I stop the application locally in visual studio, by disabling the function in azure, or by redeploying the function in azure)

My understanding is that the checkpoint should be advanced only on a successful result from the azure function, but it seems it is also advanced when the function application is stopped in between retry-runs. This makes it impossible for me to guarantee at-least-once execution of my function.

Can someone please try to explain to me, why the function is not retried after restart?

  • 1
    As far as I understand, those Retry Policies which are **in preview** don't seem to be wired/configured to be apply on the Cosmos DB Trigger, there is no code that I'm aware that is taking them into consideration in the source at https://github.com/Azure/azure-webjobs-sdk-extensions/tree/cosmos/v3.x/src/WebJobs.Extensions.CosmosDB – Matias Quaranta Jan 04 '22 at 17:58
  • 1
    Thank you for your response. I don't know but somehow they do actually work as long as the functions app is running. You are probably right though. It amazes me how this cannot already be a part of the offering. When would you ever want a cosmostrigger to "maybe" have an effect. Anyways, I switched to using the ChangefeedProcessorLibrary instead, which works perfectly, and I'll implement my own retrypolicies as needed. This is the article that led me to believe that this would work in the first place: https://dev.to/shibayan/a-quick-review-of-the-azure-functions-new-feature-retry-policy-p56 – Mattias Nordqvist Jan 05 '22 at 08:24
  • Maybe it works with some particular configuration that I'm not aware of, but if you could not get it to work there must be a gap somewhere. – Matias Quaranta Jan 05 '22 at 14:58

0 Answers0