Alternatives to returnInternalServerErrorOnFailure

[anthonywhite]

When we first built durable functions in C# under .Net 6, the Orchestration HTTP trigger code used a Microsoft.Azure.WebJobs.Extensions.DurableTask.IDurableOrchestration object with a method called CreateCheckStatusResponse. This had an optional parameter returnInternalServerErrorOnFailure which allowed us to return an HTTP 500 status code to a caller that is polling the Location endpoint (supplied in the 202 Accepted headers). This was convenient when using Logic Apps as the caller as the only check needed for errors could be on HTTP status code.

Now under .Net 8, the object model in the Orchestration HTTP trigger code has changed to a Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Client.DurableTaskClient and the CreateCheckStatusResponseAsync method of this object does not have an equivalent parameter. Also I can see from various discussions in this repo that maybe the previous approach is deprecated or possible considered plain wrong.

Is the thinking now that the caller should check runtimeStatus or a custom status attribute/object in the Location response to verify successful completion?

[cgillum]

There were definitely some debates about the previous version of CreateCheckStatusResponseAsync. Unfortunately, it's one of those things were there isn't an industry standard so it's hard to know what to go with, especially since there are conflicting examples across the web.

Is the thinking now that the caller should check runtimeStatus or a custom status attribute/object in the Location response to verify successful completion?

Yes, I think this is a good idea if possible. The old model was mostly optimized for certain low-code clients like Logic Apps where it was difficult to inject any custom logic that could actually look at the runtime status. But if you're able to add code that considers the runtime status, then that would definitely be the recommended (and frankly, most reliable) approach.