While working on durable function in azure apps i got this error while it published to online it is perfectly work in local host

Question

"message": "Function 'UpdateCustomerDetails_Orchestrator' failed with an unhandled exception.", "details": "Microsoft.Azure.WebJobs.Host.FunctionInvocationException: Exception while executing function: UpdateCustomerDetails_Orchestrator

System.InvalidCastException: Unable to cast object of type 'System.String' to type 'Microsoft.Azure.WebJobs.Extensions.DurableTask.IDurableOrchestrationContext'.

at lambda_method172(Closure, HttpTriggerFunction, Object[]) at Microsoft.Azure.WebJobs.Host.Executors.TaskMethodInvoker2.InvokeAsync(TReflected instance, Object[] arguments) in D:\\a\\_work\\1\\s\\src\\Microsoft.Azure.WebJobs.Host\\Executors\\TaskMethodInvoker.cs:line 21 at Microsoft.Azure.WebJobs.Host.Executors.FunctionInvoker2.InvokeAsync(Object instance, Object[] arguments) in D:\a_work\1\s\src\Microsoft.Azure.WebJobs.Host\Executors\FunctionInvoker.cs:line 53 at Microsoft.Azure.WebJobs.Extensions.DurableTask.OutOfProcMiddleware.<>c__DisplayClass10_0.<

this error is encountered after publishing the app it says the orchestrator is failed

Answer 1

Hi ,

Thanks for reaching out to Microsoft Q&A.

The error suggests that your orchestrator function is being treated like an HTTP-triggered function instead of a durable orchestrator function after deployment.

Why it works locally but not after publishing:

• Locally, the Durable Functions tooling may correctly associate the function with its type.
• After deployment, something in the function signature or the function.json metadata is likely off causing Azure to route an HTTP request to your orchestrator function, passing a string instead of an orchestration context object.

Root Cause:

Your orchestrator function is probably defined like this:

[FunctionName("UpdateCustomerDetails_Orchestrator")] public async Task RunOrchestrator( [OrchestrationTrigger] IDurableOrchestrationContext context) { ... }

the runtime may be misidentifying it due to:

• Wrong trigger attribute (missing or incorrect)
• Deployment mismatch
• Function name conflict
• Incorrect function.json generation
• Old bin or obj folders not cleaned up before publish

Possible resolution steps to try:

1. Double-check your function attributes: Make sure the function is properly decorated with [FunctionName("UpdateCustomerDetails_Orchestrator")] and uses [OrchestrationTrigger].
2. Clean and rebuild your project before publishing, This ensures no stale metadata or DLLs get deployed.
3. Remove bin/obj folders before publishing, to ensure a clean publish.
4. Double-check your host.json and local.settings.json: Ensure you're using the correct extension bundles and versions.
5. Verify you’re not accidentally routing HTTP calls to the orchestrator: Your HTTP trigger should start the orchestration like this:

   [FunctionName("Start_UpdateCustomerDetails")] public async Task<IActionResult> StartOrchestration( [HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequest req, [DurableClient] IDurableOrchestrationClient client) { var instanceId = await client.StartNewAsync("UpdateCustomerDetails_Orchestrator", null); return client.CreateCheckStatusResponse(req, instanceId); }

   Note that do not call UpdateCustomerDetails_Orchestrator directly via HTTP.
6. Redeploy using proper tooling (VS Publish, Azure DevOps, or func azure functionapp publish).

Please feel free to click the 'Upvote' (Thumbs-up) button and 'Accept as Answer'. This helps the community by allowing others with similar queries to easily find the solution.

Answer 2

We were experiencing the same issue, where durable orchestration works locally, but fails when deployed. We tried all the suggested resolution steps; ensured we're calling the orchestration via .StartNewAsync() in an HTTP trigger, we're deploying via Azure DevOps, using the decorators properly, and made sure all the packages are up to date. When we check in the portal, we can see the functions deployed as we would expect.

What it came down to was that we had set the runtime stack in the function app to DOTNET-ISOLATED|8.0 when it wasn't isolated. Switching the runtime stack to DOTNET|8.0 resolved the issue