I’ll skip the shenanigans. If you’re reading this, then you’ve probably already been through Stackoverflow, official documentation and all other classical sources so let’s cut to the chase and dive into these magnificent beasts, the Azure Durable Functions.
Do you really know what Durable Functions do?
Cause if you think that they are exactly like the common Azure Functions but run longer, then my dear friend, you’re mistaken. As I understand it, a durable function will run exactly like a classic function until it meets an “await” statement (triggering and Activity function). Then it will save its state and go to sleep, until the response arrives. This is good, because we don’t pay for the function while it sleeps. When the response does arrive, the durable function wakes up and …starts over. Yes, it starts over, it runs again from the beginning but! it remembers the state of all variables and won’t change it. So be very careful about what you do, your code must always be deterministic, because it will be done again and again and again and again and again and again…
Hint: Of course you want to write log-messages, don’t you? But if you do, the same log messages will appear again and again and again. Not weird at all, as the DF is re-executed. Use the CreateReplaySafeLogger command to prevent drowning your app-insights with a gazillion messages:
The Durable Function doesn’t start with the Orchestration Function.
Which is why your HTTP Trigger didn’t work. You don’t start there, you start with the client function! There are 4 types of functions and you tell them apart by triggers and bindings (those [OrchestrationTrigger], [ActivityTrigger], etc.). Instead of copying from the official documentation, I’ll show you some code, which is available here:
So instead of calling the Orchestrator function (which you can’t either way), you start by triggering the DurableClient, which then will invoke the orchestration!
