Share via

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

Nigel 25 Reputation points
2026-05-19T00:58:41.3433333+00:00

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?

Azure Functions
Azure Functions

An Azure service that provides an event-driven serverless compute platform.

Answer accepted by question author

Alex Burlachenko 21,805 Reputation points MVP Volunteer Moderator
2026-05-19T11:20:22.72+00:00

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

Was this answer helpful?

2 people found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Siddhesh Desai 7,160 Reputation points Microsoft External Staff Moderator
    2026-05-22T08:26:35.3+00:00

    Hi @Nigel

    Thank you for reaching out to Microsoft Q&A.

    The behavior you are observing is most likely caused by a runtime specialization issue during cold start in the Azure Functions Consumption plan (Windows) when using**.NET 10 isolated worker**. In the Consumption plan, Azure Functions initially starts a placeholder host (which may be Node, PowerShell, or another runtime) and then specializes it to the configured runtime (dotnet-isolated). If a mismatch is detected between the placeholder runtime and your deployed application runtime, the Functions host performs a restart. When your queue-triggered function starts execution during this transition, the host shutdown triggers a cancellation token, causing a TaskCanceledException. The message is then requeued and processed successfully on the next attempt when the correct runtime is fully initialized. This aligns with known runtime mismatch scenarios where the configured runtime and detected worker runtime metadata do not match. Additionally, while .NET 10 is supported in the isolated model, the Consumption plan relies heavily on dynamic scaling and cold start behavior, which can lead to such intermittent issues. This is why the issue does not occur in Premium plans, where instances are pre-warmed and do not undergo the same specialization process. [learn.microsoft.com] [Guide for...soft Learn | Learn.Microsoft.com], [Azure Func...soft Learn | Learn.Microsoft.com]

    Refer below points to resolve this issue or this is the workaround

    Move to Flex Consumption plan (recommended workaround) The current Consumption plan is considered legacy and relies heavily on cold starts. Flex Consumption provides improved cold start handling, better scaling behavior, and supports .NET 10 isolated reliably. Migrating to this plan minimizes runtime specialization issues without incurring the full cost of Premium.

    Ensure retry and idempotent processing for queue triggers Since the failure occurs during host restart and the message is reprocessed successfully, implement idempotent logic to safely handle retries. This ensures no duplicate side effects when the same message is processed again after requeue.

    Validate runtime configuration consistency Ensure that your Function App settings are aligned correctly to avoid any additional mismatch issues:

    • FUNCTIONS_WORKER_RUNTIME = dotnet-isolated
    • FUNCTIONS_EXTENSION_VERSION = ~4
    • Confirm no old artifacts (in-process or different runtime payloads) are deployed

    Disable placeholder optimization (optional check) If not already set, verify the setting below to reduce mismatch during specialization:

    WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED = 0

    Note that this may not fully resolve the issue but can reduce occurrences in some scenarios.

    Reduce cold start impact where possible Introduce warm-up strategies (such as periodic timer triggers) to minimize the chances of cold start and runtime re-specialization, which is when this issue typically occurs.

    Consider temporary downgrade to .NET 8 or .NET 9 (if impact is critical) If the issue is affecting production stability, rolling back to a more mature runtime version can provide immediate stability until improvements for .NET 10 in Consumption plan are available.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.