Azure-functions-durable-extension: Default to a hubname if none provided (v2)

[jeffhollan]

Currently if you spin up a new Durable v2 project and try to run without updating the host.json you get the following:

[7/16/19 9:41:19 PM] A host error has occurred
[7/16/19 9:41:19 PM] Microsoft.Azure.WebJobs.Extensions.DurableTask: A non-empty HubName configuration is required.
Value cannot be null.
Parameter name: provider

Ideally if the host.json is blank we would have intelligent defaults so the project could still run

[jeffhollan]

Suspect the same is true for the storageProvider property

[cgillum]

cc @ConnorMcMahon

This is by design. Having a default hub name led really difficult to diagnose problems for customers. Basically, any time a customer used the same storage account for two different function apps (whether deployed locally or in Azure) the two apps would steal messages from each other and cause unpredictable behavior.

Another solution we considered was defaulting to the site name. Connor and I were concerned about this too because of the potential to cause issues when using slots - even if we also included the slot name in the default task hub name. I forget what the exact concerns were, but @ConnorMcMahon maybe you remember?

We ultimately decided to just make explicitly specifying a task hub name a requirement in v2 since it's the easiest solution and we can always change our minds later. If you feel strongly about this, we can revisit and try to come up with other solutions.

[jeffhollan]

Thanks for the context. Maybe something we could even help solve for on the tooling side? Not sure. Pretty much everytime I create a durable v2 app I have to open the docs and copy paste the host.json sample because I don’t remember the schema, so some way to make that easier. Definitely sympathize with the people attaching different functions to same storage account though if a globally constant default taskhub name.

[ConnorMcMahon]

I believe the concern had to do with the slot-swap behavior, where using the slot name no longer worked. There was also the potential to use the site name with the deployment id, but I believe that wasn't accessible on Linux.

[jeffhollan]

Can you specify the hub name in the method declaration / function.json? Maybe in the docs and samples we just switch to something like:

public class Counter
{
    [FunctionName(nameof(Counter))]
    public static Task Run([EntityTrigger(HubName = “UniqueHubName”] IDurableEntityContext ctx)
        => ctx.DispatchAsync<Counter>();
}

So at least it’s a bit easier for them to know to edit?

[cgillum]

I'm not really a fan of that approach because it would require you to add it for every function (orchestrations, activities, and entities). Typically you want the entire function app to use the same app hub name. Explicit names in the function declaration are intended for advanced scenarios.

If we don't want to force folks to use host.json, I would suggest we revisit defaulting to the function app name with slot info for non-production slots. Of course, this means we would need to make sure that all platforms have the environment variables we need, but I would say lets not block on that (as an aside, defaulting to the site name would also make correlating trace data in Kusto easier - I'm currently writing the TSG for this :)).

[BarnyardTech]

How would this look in the host.json file? When I looks at docs for host.json I don't see reference to HubName.

[amdeel]

@BarnyardTech
Currently, in V2, we are requiring users to specify a task hub name.

Here's a link to some documentation on Task Hubs, including host.json examples:
https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-task-hubs

My fix to this issue will assign a default task hub name if no hub name is specified in the host.json file. However, we are still recommending users specify their task hub names. This new default is best for new users who want to quickly start a project without running into an exception.