Azure-functions-durable-extension: Task Hub name must be specified in host.json when using slots

[salv85]

Describe the bug

When I deploy a Durable Functions App to Function App, it said

The function runtime is unable to start. Microsoft.Azure.WebJobs.Extensions.DurableTask: Task Hub name must be specified in host.json when using slots.

Investigative information

Durable Functions extension version: 2.0.0
Function App version (1.0 or 2.0): 2.0
Programming language used: C#

My host.json file content:

{
  "version": "2.0",
  "extensions": {
    "durableTask": {
      "hubName": "%SlotTaskHub%"
    }
  }
}

My settings.json _(main slot)_:

{
  "IsEncrypted": false,
  "Values": {
    "SlotTaskHub": "MainHubName"
  }
}

My settings.json _(dev slot)_:

{
  "IsEncrypted": false,
  "Values": {
    "SlotTaskHub": "DevHubName"
  }
}

My client function:

[FunctionName("MyFunctionName")]
public async Task<HttpResponseMessage> MyFunctionAsync([HttpTrigger(AuthorizationLevel.Anonymous, "POST")]HttpRequestMessage request,
    [DurableClient(TaskHub = "%SlotTaskHub%")]IDurableOrchestrationClient starter)
{
    //My code here
}

Expected behavior
Successfully works in both slots with different TaskHub names and the same storage account.

Actual behavior
If deployed to the main slot, it works.
If deployed to other slots, I receive the error.

Additional context

• Development environment (ex. Visual Studio) Visual Studio 2019
• Additional bindings used HttpTrigger or ServiceBusTrigger

[anthonychu]

Related https://github.com/MicrosoftDocs/azure-docs/issues/41177

[anthonychu]

It should also be possible to omit hubName from host.json and set the hub name with an app setting called AzureFunctionsJobHost__extensions__durableTask__hubName. It works in a production slot (can confirm that storage containers are created with the supplied name). However, it's not working in non-production slots either.

[mpaul31]

@anthonychu I am running into the same issue. The documentation is not clear to me, so if I have my prod slot and stage slot using the same storage account BUT different task hub names is it required I set the TaskHub property like this?

[DurableClient(TaskHub = "%SlotTaskHub%")]IDurableOrchestrationClient starter

[anthonychu]

@cgillum What's the currently recommendation for slots? Does it work and scale properly when the hub name is set this way?

[DurableClient(TaskHub = "%SlotTaskHub%")]IDurableOrchestrationClient starter

[mpaul31]

Just to be clear, I am specifying the TaskHub in my host.json but I am getting the same error message as the author so I was wondering if I also need it as an app setting and configured in the trigger.

The function runtime is unable to start. Microsoft.Azure.WebJobs.Extensions.DurableTask: Task Hub name must be specified in host.json when using slots.

Right now I am just throwing darts at the wall trying to get my slots working.

[anilripla]

Is this fixed? I continue to get this error in Azure slot.

The function runtime is unable to start. Microsoft.Azure.WebJobs.Extensions.DurableTask: Task Hub name must be specified in host.json when using slots.

I am currently downgrading Nuget pkg to 1.8.5 as a temporary workaround to prevent function crashing.

[ConnorMcMahon]

@anilripla

A couple of questions.

1. Are you using 2.1.1?
2. Is the TaskHub name that you are using equal to the default task hub name (aka your site name stripped of non-alphanumeric characters?)

[anilripla]

Yes , I am using 2.1.1 , the Task Hubname is different from the default task hub.

host.json

{
  "version": "2.0",
  "extensions": {
    "durableTask": {
      "hubName": "%MyTaskHub%",
      "azureStorageConnectionStringName": "DurableManagementStorage"
    }
  }
}

app settings

  "Values": {
    "MyTaskHub": "staginghubname"
  }

Seems that the Task Hubname is not being read from the app settings?

Temporarily downgrading to 1.8.5 gets function working again.

[ConnorMcMahon]

@anilripla

Could you share you function app name (you can do so privately)?

This bug is fixed in all of the scenarios I have been able to reproduce, so seeing your app's telemetry could help me diagnose.

In the meantime, stay on 1.8.5 unless I can get you a workaround.

[anilripla]

function app name : rclfunctions - staging (staging slot)

App Insights is not set up for the function app. Do I need to set it up for you to diagnose?

[ConnorMcMahon]

@anilripla

No we have our own internal telemetry that does not depend on App Insights.

[ConnorMcMahon]

@anilripla I took a look at your application and slot and did not find the app setting "MyTaskHub". Are you sure the values you are setting are not in your local.settings.json? In general, you can verify if your app settings you are testing locally with are deployed to Azure by checking your app settings in the portal.

[rcladmin]

I removed the app settings when I downgraded the Nuget package. I was able to get the durable function to start back working at 1.8.2 in both staging and production slots. I also removed the Task Hub and use separate storage accounts for staging and production. Its a live production app and I need both prod/staging up and running.

I intend to do some testing on a separate dev function to see if I can get 2.2.1 working for me. Will post my findings when I am done.

[jjcollinge]

@ConnorMcMahon think I'm still seeing this on 2.1.1 and 2.2.0.

I have a host.json with the following contents:

{
  "version": "2.0",
  "extensions": {
    "durableTask": {
      "hubName": "%CustomHubName%"
    }
  }
}

I use the attribute [DurableClient(TaskHub = "%CustomHubName%")]IDurableClient client.
I then set the CustomHubName appsetting differently per slot and it does not match the app name but still receive the error.

Task Hub name must be specified in host.json when using slots. Specified name must not equal the default HubName.

In fact even when not using slots, the appsetting or host.json value is never used and it always uses the default task hub name.

I've tried using setting AzureFunctionsJobHost__extensions__durableTask__hubName with and without a value in the host.json too but still it uses the default.

I've also tried putting a hardcoded value in the host.json instead of an appsetting and again it still uses the default.

Note: it works as expected locally, but when deployed to an Azure Function (v3) it doesn't.

[ConnorMcMahon]

@jjcollinge, could you provide your application name (instructions for how to do so privately are above).

[jjcollinge]

@ConnorMcMahon thanks for getting back to me, I'll provide you with some details later this week.

[jjcollinge]

@ConnorMcMahon just an FYI, the customer decided not to use slots in the end so we didn’t end up needing to fix this. However, I’ve told them to pick up this thread if they do decide to try and use slots at a later point and hit this issue again.

[sanjaydebnath]

@ConnorMcMahon think I'm still seeing this on 2.1.1 and 2.2.0.

I have a host.json with the following contents:

{
  "version": "2.0",
  "extensions": {
    "durableTask": {
      "hubName": "%CustomHubName%"
    }
  }
}

I use the attribute [DurableClient(TaskHub = "%CustomHubName%")]IDurableClient client.
I then set the CustomHubName appsetting differently per slot and it does not match the app name but still receive the error.

Task Hub name must be specified in host.json when using slots. Specified name must not equal the default HubName.

In fact even when not using slots, the appsetting or host.json value is never used and it always uses the default task hub name.

I've tried using setting AzureFunctionsJobHost__extensions__durableTask__hubName with and without a value in the host.json too but still it uses the default.

I've also tried putting a hardcoded value in the host.json instead of an appsetting and again it still uses the default.

Note: it works as expected locally, but when deployed to an Azure Function (v3) it doesn't.

Exactly same happening to me with 2.2.0, tried all the combinations mentioned. Why this issue is closed? This is an easy repro. Not able to using slot is a bummer.

[romantitov]

I'm also facing the same issue with different versions from 2.0.0 to 2.2.1 and azure function V3 and .Net Core 3.1
But when I've changed my function to V2 it fixed the issue for me.
I think the issue should be reopened, but I hope my workaround can help someone for who is not critical to use V3

[NVFedorov]

Same issue with .net core 3.1 and functions v3. Locally works fine, but when deployed to Azure, the following error appears: Microsoft.Azure.WebJobs.Extensions.DurableTask: Task hub name '%TaskHubName%' should contain only alphanumeric characters excluding '-' and have length up to 50. The name in my settings file is "TaskHubName": "taskhubname001"

[ConnorMcMahon]

@NVFedorov, that seems like a different exception than the one in this issue. Please file a separate issue for this.

As for the others in this thread, this exception may fire if either of the following are true.

1. The TaskHub name that is specified matches your application name after you strip out - characters and take the first 45 characters. This is because this is the default task hub name we would select if you have not provided one, so we are still throwing the exception.
2. Your host.json configuration is not being loaded. This can happen if you override the IConfiguration in your Startup.cs dependency injection.

If you believe you are still encountering this exception and do not meet either of these cases, please file a separate issue to track this.

[ltdu]

Thanks, @ConnorMcMahon!

For us problem was

1. Your host.json configuration is not being loaded. This can happen if you override the IConfiguration in your Startup.cs dependency injection.

Removing this part from Startup.cs solved this problem:

...
var services = builder.Services;
var config = new ConfigurationBuilder()
    .AddEnvironmentVariables()
    .Build();
services.AddSingleton<IConfiguration>(config);
...

[ConnorMcMahon]

For reference for anyone who wants to customize configuration, Azure Functions now has a proper way to handle this: https://docs.microsoft.com/en-us/azure/azure-functions/functions-dotnet-dependency-injection#customizing-configuration-sources.