Every Activity Will Run Twice: Idempotency in Durable Functions
Learn how to make every Durable Functions activity idempotent so retry policies can safely rerun SharePoint and Graph provisioning steps.
Durable Functions
Durable Functions in practice: checkpointing, idempotent activities, deterministic instance IDs, and telling a permanent failure from a transient one.
Durable Functions solved a problem I had been solving badly by hand: work that takes longer than a request, needs to survive a restart, and must not repeat the expensive parts when it resumes.
The posts here are the lessons in the order I learned them. What a durable orchestration actually is, and why a function that sleeps for a week is a reasonable thing to build. Checkpointing, so a retry moves forward rather than starting again. Idempotent activities, because every activity will eventually run twice. Deterministic instance IDs, so two messages about the same site do not start two orchestrations. And telling a permanent failure apart from a transient one before you retry it forty times.
Most of this came out of provisioning work, so the two topics overlap heavily.
Start here: Durable Functions: A Function That Sleeps for a Week
Provision Forward, Never Backward: Checkpointing Durable Functions
Learn how to checkpoint a Durable Functions orchestration so a failed SharePoint provisioning run resumes where it stopped instead of starting over.
Durable Functions: A Function That Sleeps for a Week
Learn what Azure Durable Functions are and what they can do, using a SharePoint site provisioning workflow as a real-world example.
No posts match — try another search.