The changes between the two were relatively minor, but one gotcha with Durable Functions and Azure Functions V2 revolves around using the CreateCheckStatusResponse method of DurableOrchestrationClient.

Here's my starter function that kicks off a new orchestration. Notice that it takes a HttpRequestMessage parameter and returns a HttpResponseMessage:

This compiles just fine in Azure Functions V2, but if you use the templates to create a new HTTP triggered function, then you'll end up with a function that takes a HttpRequest and returns an IActionResult. This prevents you from using the CreateCheckStatusResponse method in these new-style HTTP triggered functions.

The good news is that there is now a new CreateHttpManagementPayload method that generates a JSON payload containing the correct URIs for the management APIs for this orchestration that you can use for the response. So here's an updated version of my starter function that uses the new-style function signature.

Custom Orchestration Status

Another great recently added feature is the ability to store a custom orchestration status against any running orchestration. The orchestrator function can set this value by calling SetCustomStatus on the DurableOrchestrationContext.

When you use the REST API to query the status of a running orchestration, you get to see the value of this custom status, making it great for tracking how far through the workflow you are.

For example, you might just update it with a simple string just before calling an activity or sub-orchestration:

ctx.SetCustomStatus("sending approval request email");

This would result in the following when we queried the status for this instance:

But you're not limited to strings. You can store any serializable object in there, so it could include the IDs of sub-orchestrations that have been kicked off, or URLs of files that have been created in blob storage or IDs of rows that have been added to a database. It's a simple feature, but very powerful if you want to make your workflows easier to diagnose.

Enumerating Instances

Another great new feature in 1.5, is that now we can call an API (or use the GetStatusAsync method on the DurableOrchestrationClient) to retrieve details of all orchestrations stored in the task hub. This allows you to discover the orchestration ids of any running orchestrations, if you'd failed to keep track of them.

I think that management APIs like this will be vital in persuading developers to be willing to give Durable Functions a go in production. However, I think it needs to go further and give us support for paging and filtering the orchestrations (as there could be a vast number of them if Durable Functions is being used heavily), and it would also be good to be able to purge the event sourcing history of old Durable Functions from the task hub, either to simply clean up and save space, or as part of a required data retention cleanup.

I've submitted a GitHub issue with my desired enhancements to this feature, so do get involved in the discussion if you think this is something that would be useful to you as well.

About Mark Heath

I'm a Microsoft MVP and software developer based in Southampton, England, currently working as a Software Architect for NICE Systems. I create courses for Pluralsight and am the author of several open source libraries. I currently specialize in architecting Azure based systems and audio programming. You can find me on: