Azure Durable Task Scheduler: Does changing hubName auto-provision a new Task Hub, or is pre-provisioning required

Question

Azure Durable Task Scheduler: Does changing hubName auto-provision a new Task Hub, or is pre-provisioning required

Leo Liu 40

Context

We're running an Azure Durable Functions v4 app (Node.js, durable-functions SDK v3) that uses the Azure Managed Durable Task Scheduler as its storage provider — not the legacy Azure Storage backend.

Our host.json configuration:


{
  "extensions": {
    "durableTask": {
      "hubName": "%TASKHUB_NAME%",
      "storageProvider": {
        "type": "azureManaged",
        "connectionStringName": "DURABLE_TASK_SCHEDULER_CONNECTION_STRING"
      }
    }
  }
}

We're implementing a zero-downtime deployment strategy using deployment slots + dynamic Task Hub isolation. The idea is:

Each deployment to the staging slot injects a new, unique TASKHUB_NAME (e.g., ScheduledTransfers_20260310_42) via environment variable.
The staging slot starts up and connects exclusively to the new Task Hub — fully isolated from the production slot's in-flight orchestrations on the old Task Hub.
After warm-up, we execute a slot swap. The old slot (now staging) continues draining its orchestrations on the old Task Hub until completion.
The next timer trigger fires in the new production slot, starting fresh orchestrations on the new Task Hub.

This pattern prevents NonDeterministicWorkflowException when breaking changes are deployed while long-running orchestrations (several hours) are still in flight.

The Question

With the Azure Managed Durable Task Scheduler ("type": "azureManaged"):

Does setting a new TASKHUB_NAME value against an existing DURABLE_TASK_SCHEDULER_CONNECTION_STRING automatically provision a new Task Hub at runtime? Or do we need to pre-create the Task Hub resource (via Bicep/ARM/CLI) before the Function App starts?
If pre-provisioning is required, what is the recommended approach?
- az durabletask taskhub create CLI command in CI/CD?
- Bicep Microsoft.DurableTask/schedulers/taskHubs resource?
- Some other method?
Cleanup: What is the recommended way to decommission/delete old Task Hubs after their orchestrations have fully drained? Is there an API or CLI command to check for zero in-flight instances and then safely delete?

Environment

ComponentVersion / DetailAzure Functions Runtimev4@azure/functions4.8.0durable-functions3.2.0Extension BundleMicrosoft.Azure.Functions.ExtensionBundle.Preview [4.37.0, 4.38.0)Storage ProviderazureManaged (Durable Task Scheduler)LanguageTypeScript / Node.js >= 18HostingDedicated App Service Plan (not Consumption)Any guidance or pointers to documentation would be greatly appreciated. Thanks!

Siddhesh Desai 4,815 Reputation points Microsoft External Staff Moderator

2026-03-10T04:06:36.11+00:00
Hi @Leo Liu

Thank you for reaching out to Microsoft Q&A.

When using Azure Managed Durable Task Scheduler (storageProvider.type = azureManaged), the behavior of Task Hub creation is different from the legacy Azure Storage provider. With the Azure Storage backend, Durable Functions automatically create the Task Hub (queues/tables) at runtime when the host starts. However, with the Azure Managed Durable Task Scheduler, Task Hubs are first‑class ARM resources under the scheduler. As a result, changing the hubName alone does not auto‑provision a new Task Hub at runtime. If the Function App (or slot) starts with a TASKHUB_NAME that does not already exist in the scheduler, the host cannot connect to it. This is why zero‑downtime deployment patterns that dynamically inject new Task Hub names require explicit pre‑provisioning of each Task Hub before the Function App starts.

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

1. Pre‑create the Task Hub before starting the Function App (Required)

For azureManaged storage provider, every new TASKHUB_NAME must exist in the Durable Task Scheduler ahead of time.

Task Hubs are ARM resources under

Microsoft.DurableTask/schedulers/taskHubs

Creation must happen before the slot starts or is swapped

2. Use Azure CLI (recommended for CI/CD pipelines)

Microsoft provides an official Durable Task Scheduler CLI extension that supports Task Hub lifecycle operations.

az extension add --name durabletask az durabletask taskhub create \ --resource-group <rg-name> \ --scheduler-name <scheduler-name> \ --name <taskhub-name>

3. Use Bicep / ARM for Infrastructure‑as‑Code environments If you manage infrastructure declaratively, Task Hubs can be created as ARM resources.

resource taskHub 'Microsoft.DurableTask/schedulers/taskHubs@2025-11-01' = { name: '${schedulerName}/${

Best suited for controlled environments

Less flexible for per‑deployment dynamic hub names, but fully supported

4. Slot‑based zero‑downtime deployment pattern is valid and supported Your approach of:

Generating a new Task Hub per deployment

Letting the old slot drain orchestrations on the old hub

Swapping slots only after warm‑up

is a recommended strategy to avoid NonDeterministicWorkflowException when deploying breaking changes with long‑running orchestrations.

5. Safely clean up old Task Hubs after orchestrations drain Task Hubs can be deleted once no running or pending orchestrations remain.

az durabletask taskhub delete \ --resource-group <rg-name> \ --scheduler-name <scheduler-name> \ --name

Recommended cleanup approach:

Verify zero in‑flight instances via the Durable Task Scheduler dashboard or APIs

Automate cleanup based on age / deployment metadata

Delete only hubs with no active orchestrations
Siddhesh Desai 4,815 Reputation points Microsoft External Staff Moderator

2026-03-11T04:26:50.0933333+00:00

Hi @Leo Liu

Can you check the answer provided by me below:

If the resolution was helpful, kindly take a moment to click on and click on Yes for was this answer helpful. And, if you have any further query do let us know.
Siddhesh Desai 4,815 Reputation points Microsoft External Staff Moderator

2026-03-13T08:12:44.9333333+00:00

Hi @Leo Liu

Can you check the answer provided by me below:

If the resolution was helpful, kindly take a moment to click on and click on Yes for was this answer helpful. And, if you have any further query do let us know.
Praveen Kumar Gudipudi 2,195 Reputation points Microsoft External Staff Moderator

2026-04-02T14:12:41.6966667+00:00
hello @leo liu

When using Azure Durable Functions with the Azure Managed Durable Task Scheduler (storageProvider.type = "azureManaged"), you do not need to pre-provision Task Hubs.

If the Function App starts with a new hubName that does not already exist, the Durable Functions runtime will automatically create and initialize the Task Hub within the configured Durable Task Scheduler. Therefore, simply changing the TASKHUB_NAME environment variable is sufficient, and no additional ARM/Bicep/CLI provisioning step is required.

Your configuration is valid:

{

"extensions": {

"durableTask": { "hubName": "%TASKHUB_NAME%", "storageProvider": { "type": "azureManaged", "connectionStringName": "DURABLE_TASK_SCHEDULER_CONNECTION_STRING" } }

}

}

When the host starts and connects using a new value such as ScheduledTransfers_20260310_42, the runtime will create the corresponding Task Hub if it does not already exist.

Deployment Strategy

Your deployment slots + dynamic Task Hub isolation approach is a valid strategy for avoiding breaking changes in long-running orchestrations.

Typical workflow:

Deploy the new version to the staging slot.

Provide a new TASKHUB_NAME via environment variable.

Start the staging slot so it connects to the newly created Task Hub.

Warm up the slot.

Perform a slot swap.

The previous slot continues draining orchestrations from the old Task Hub.

New orchestrations start on the new Task Hub.

This approach helps avoid NonDeterministicWorkflowException when deploying updates that modify orchestration logic while long-running instances are still executing.

Cleaning Up Old Task Hubs

Task Hubs created during deployments are not automatically deleted, so cleanup should be handled separately.

Recommended approach:

Ensure that no orchestrations remain in Running or Pending states in the old hub.

After all instances complete, remove the hub using management tooling (for example via CLI if available) or through scheduler management operations.

In practice, many teams automate cleanup by:

Retaining hubs for a short safety window (for example 7–14 days).

Periodically removing hubs that have no active orchestrations.