3

I have 2 Durable Functions running on the same storage account - one has the default hub name while the other is specified in the host.json.

Each Durable Function has a function named "RunOrchestrator" and it seems that when new jobs are added to MyUtilityExecutorHub their data is then being stored in the DurableFunctionsHubInstances table of the other function.

This is what the host.json file looks like for the second function.

{
  "version": "2.0",
  "extensions": {
    "durableTask": {
      "hubName": "MyUtilityExecutorHub"
    }
  }
}

The host.json for the second function is as above when viewing in Kudu, so why are the jobs going to the wrong backing storage tables?

Edit: The easy fix for this in our scenario for the sake of never having to deal with it again is to have a storage account per function, but I'd like to get to the bottom of it!

David C
  • 501
  • 1
  • 4
  • 16
  • have you looked at this doc:https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-perf-and-scale#storage-account-selection – Ketan Nov 11 '19 at 08:24
  • Sounds strange. Have you tried to specify the name via app setting (%hubnamesetting%) ? Or could you please try to specify it in the OrchestrationClient ( [OrchestrationClient(TaskHub = "%MyTaskHub%")]) just to be sure it isnˋt something with the host.json settings. – Sebastian Achatz Nov 13 '19 at 19:27
  • Didn't know you could do it that way. We've it mitigated now by separate storage accounts but if I get some time I'll put together a test harness to replicate it. Thanks for the alternatives! – David C Nov 15 '19 at 10:39
  • attempted setting this in app config settings in azure, didn't work – Jake Boomgaarden Nov 02 '22 at 12:12

1 Answers1

1

from the document:

The name is what differentiates one task hub from another when there are multiple task hubs in a shared storage account. If you have multiple function apps sharing a shared storage account, you must explicitly configure different names for each task hub in the host.json files. Otherwise the multiple function apps will compete with each other for messages, which could result in undefined behavior, including orchestrations getting unexpectedly "stuck" in the Pending or Running state.

Ketan
  • 1,530
  • 7
  • 16
  • 1
    Yes but what I posted is from reality! Hence the SO question... We've split them into separate storage accounts as we can't risk this mess happening in production. – David C Nov 11 '19 at 09:49
  • 1
    PS did you actually read what I said in the original question? – David C Nov 11 '19 at 09:50