.StartNewAsync() and .RestartAsync() fail, when running locally and TaskHubName='TestHubName'

[scale-tone]

This is a follow-up on #1592. It turned out, that, when running outside Azure, DurableFunctionsMonitor fails to .RestartAsync() and/or .StartNewAsync(), if the Task Hub it is attached to is named 'TestHubName'. With other Task Hubs it works fine. It also works fine (no matter what Task Hub is called) in Azure.

I believe it is due to this logic here, that turns on/off orchestration name validation.

Can we think of a better way to invoke that logic?

FYI, DfMon's code, that makes the call, is here.

Expected behavior

Both .StartNewAsync() and .RestartAsync() succeed.

Actual behavior

System.Private.CoreLib: Exception while executing function: DfmPostOrchestrationFunction. Microsoft.Azure.WebJobs.Extensions.DurableTask: The function 'MapReduceOrchestrator' doesn't exist, is disabled, or is not an orchestrator function. 
Additional info: No orchestrator functions are currently registered!.

is thrown, when Task Hub is named 'TestHubName'.

App Details

• Durable Functions extension version (e.g. v1.8.3): 2.4.3
• Azure Functions runtime version (1.0 or 2.0): 3.0
• Programming language used: C#

[cgillum]

Have you tried setting ExternalClient = true?

[DurableClient(TaskHub = Globals.TaskHubRouteParamName, ExternalClient = true)] IDurableClient durableClient, 

[scale-tone]

Just tried. Weirdly, that value gets discarded once Task Hub is 'TestHubName' (and still takes its effect otherwise):

And yes, it still throws then.

[cgillum]

Interesting, I think we'll need to create a local repro for this to see why the attribute value isn't sticking. I couldn't immediately see anything in the code that would cause this behavior.

[scale-tone]

You can use DfMon as a repro. Just run it locally and press 'Restart' button

, once connected to a 'TestHubName' hub.

But that ExternalClient setting - is it documented somewhere? What's the expected behavior of it?

[scale-tone]

I think I've found a workaround.
Setting WEBSITE_SITE_NAME env variable to something, e.g. to http://localhost:<my-port-nr> , does seem to turn that validation off.
But I'm really curious whether it has a potential of breaking something else. Do you think it can be safe, @cgillum ?

[cgillum]

That workaround sounds very counter-intuitive to me, but then again, the problem you're running into also seems counter-intuitive to me :). FWIW, that environment variable is already set when deployed to Azure Functions. The only problem I can think of is if your port number in the environment variable is different from the port number used in the Functions core tools (which defaults to 7071).

[scale-tone]

that environment variable is already set when deployed to Azure Functions

Yes, which is probably the reason why it all works fine in Azure.

That workaround sounds very counter-intuitive to me, but then again, the problem you're running into also seems counter-intuitive to me :).

Two minuses usually make one plus, so let us think you're somewhat positive about this :)
Allright then, will issue a patch for DfMon, until this one is properly resolved.

[davidmrdavid]

Just doing some triaging here :-)

@scale-tone is this issue still reproducible on your end? If so, is there any chance you could attach a minimal repro to this thread? That would help accelerate / re-active this investigation. Thanks!

[scale-tone]

@davidmrdavid , this behavior is still the same, even with latest Microsoft.Azure.WebJobs.Extensions.DurableTask v2.6.1.

To reproduce, create a Function project, use "TestHubName" as a Task Hub name, get a default instance of DurableClient and call its .StartNewAsync() method with random parameters. Run all of this locally (not in Azure)