Task cancelled exceptions, Azure Function App .net 10 consumption plan

Question

Since upgrading our isolated worker function apps on windows consumption plans to .net 10 we are seeing ~5-7% of our Azure storage queue trigger function invocations failing with task cancelled exceptions. When the exception occurs the message is requeued and processes successfully.

From looking at debug logs from the host we think is the issue is the function host is starting a certain runtime sepcialisation. Our function is then triggered and the work starts, the Host then says that the runtimes do not match so it restarts.

Some example logs:

One where the host says the original runtime is node:

testing-task-can-node-bad.log

One where the host says the original runtime is dotnet but has the wrong version:

2026-05-06T02-28-50Z-b7dae51335.log

One where the original runtime is powershell:

cns-test-image-process-issue.log

If we are lucky this issue will not happen if on first run the host starts up with the original runtime matching ours which is .net 10, dotnet-isloated:

2026-05-06T02-58-48Z-0c6dceee4b.log

Troubleshooting we have tried:

• We have tested function app premium plans and this issue does not appear. Moving to premium plans would significantly increase our costs.
• Enabled / disabled the dotnet-isolated placeholder
• Recreate the function apps from scratch
• reducing our scale out from 5 down to 1 as maybe it was a shutdown from a scale in
• Updated nuget packages to the latest versions

Has anyone else run into this issue?

Answer 1

hi 64898199 (good account name btw) & thanks for join me here at Q&A portal,

supported scenario but ur logs show platform specialization race on Consumption, escalate with those logs, this seems like a real consumption plan specialization bug regression, not ur queue code. .NET 10 isolated is supported on Windows Consumption but what u describe is the host starting from the wrong placeholder /runtime state, beginning queue execution & restarting because runtime metadata does not match. That would explain TaskCanceledException, requeue then successful retry. Microsoft announced .NET 10 isolated support across Functions hosting plans except Linux Consumption, so this should be supported but u know support does not mean every placeholder path is bug free. Since Premium doest reproduce and reducing scale out did not fix it, this points pretty strongly to Consumption cold-startbehavior.

I would open Azure Functions support ticket with the bad logs showing original runtime as node/powershell/wrong dotnet version, app names, region, timestamps, and note: Windows Consumption + .NET 10 isolated + storage queue trigger starts invocation before specialization completes, then host restarts due to runtime mismatch.

For mitigation, keep retries(u already have that), consider Premium if cost allows or temporarily roll back to .NET 9/8 if business impact is high. pls see FUNCTIONS_WORKER_RUNTIME=dotnet-isolated, FUNCTIONS_EXTENSION_VERSION=~4, target framework net10.0, latest worker packages & remove any stale app settings like old FUNCTIONS_WORKER_RUNTIME_VERSION.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal