Use Azure Durable Function TaskHub name set from Azure App Configuration

Question

Is it possible to set the TaskHub name for an Azure Durable Function from a value stored in the Azure App Configuration Service? My host.json file is:

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

And I'm trying out using a binder in my Orchestration client:

[FunctionName("Test_HttpStart")]
public static async Task<HttpResponseMessage> HttpStart(
    [HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequestMessage req,
    IBinder binder)
{
    var starter = await binder.BindAsync<IDurableOrchestrationClient>(
        new DurableClientAttribute { TaskHub = Configuration["TaskHubName"] });

This works when I have TaskHubName defined in local.settings.json:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet",
        "TaskHubName": "TestTaskHubName"
}

But when I remove it from local.settings.json and instead retrieve this value from Azure App Configuration:

Configuration = new ConfigurationBuilder()
    .AddAzureAppConfiguration(options =>
    {
        _ = options.Connect(Environment.GetEnvironmentVariable("app-configuration-connection-string"))
            .Select(@"TaskHubName");
    })
    .AddEnvironmentVariables()
    .Build();

I receive the error:

Microsoft.Azure.WebJobs.Extensions.DurableTask: Task hub name '%TaskHubName%' should contain only alphanumeric characters, start with a letter, and have length between 3 and 45. Microsoft.WindowsAzure.Storage: Invalid container name. Check MSDN for more information about valid container naming.

So even though I can see the value from Azure App Configuration is pulled down and exists in the application's configuration it doesn't appear like it is being used. Is it possible to use a value from Azure App Configuration as the Durable Function's TaskHub name?

Answer 1

The runtime binding should work but the error is likely coming from the startup sequence, which fetches the value from host.json which is used for the rest of the functionality like internal queue triggers.

Unfortunately, AFAIK there isn't a way to work around this now.

You could however up vote this feature request to support app configuration references that should support this scenario.