0
votes

I am new to azure durable functions. According to documents that the orchestrator functions are reliable. But I am wondering if the the starter function is reliable. Suppose that I have a http-trigger orchestrator functions. I guess when durable function framework (or something run in backend) detects that an http request matches a orchestrator function, it starts the starter function to trigger the orchestrator function. I am wondering where the starter function runs, a VM? Can the VM fail? I cannot find much doc on msdn.

1
Yes, Orchestrator client is reliable.Agrawal Shraddha
Thanks for your reply, Agrawal. Any docs online?azhang
@azhang Did my answer help you?Cindy Pau
no. that's not I want.azhang

1 Answers

1
votes

Orchestrator functions reliably maintain their execution state by using the event sourcing design pattern. Instead of directly storing the current state of an orchestration, the Durable Task Framework uses an append-only store to record the full series of actions the function orchestration takes. An append-only store has many benefits compared to "dumping" the full runtime state. Benefits include increased performance, scalability, and responsiveness. You also get eventual consistency for transactional data and full audit trails and history. The audit trails support reliable compensating actions.

Durable Functions uses event sourcing transparently. Behind the scenes, the await (C#) or yield (JavaScript) operator in an orchestrator function yields control of the orchestrator thread back to the Durable Task Framework dispatcher. The dispatcher then commits any new actions that the orchestrator function scheduled (such as calling one or more child functions or scheduling a durable timer) to storage. The transparent commit action appends to the execution history of the orchestration instance. The history is stored in a storage table. The commit action then adds messages to a queue to schedule the actual work. At this point, the orchestrator function can be unloaded from memory.

When an orchestration function is given more work to do (for example, a response message is received or a durable timer expires), the orchestrator wakes up and re-executes the entire function from the start to rebuild the local state. During the replay, if the code tries to call a function (or do any other async work), the Durable Task Framework consults the execution history of the current orchestration. If it finds that the activity function has already executed and yielded a result, it replays that function's result and the orchestrator code continues to run. Replay continues until the function code is finished or until it has scheduled new async work.

Offcial doc