azure-functions-durable-extension: Unable to load hubName from appsettings for durable function
Description
According to the documentation found at https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-task-hubs#hostjson-functions-20-1, it should be possible to use a value from the appsettings as the hubname in the host.json file. However, after updating Microsoft.Azure.WebJobs.Extensions.DurableTask to v2.1.0, an exception is now thrown during startup.
Expected behavior
When using “%MyTaskHub%” as the value of the “hubName” property in the host.json file, I’m expecting the runtime to look for a key matching “MyTaskHub” in the appsettings and use its value as the hub.
Actual behavior
When the function app starts up, I receive an exception:
System.Private.CoreLib: Exception has been thrown by the target of an invocation. Microsoft.Azure.WebJobs.Extensions.DurableTask: Task hub name ‘%MyTaskHub%’ should contain only alphanumeric characters excluding ‘-’ and have length up to 45. Microsoft.WindowsAzure.Storage: Invalid container name. Check MSDN for more information about valid container naming. Value cannot be null. (Parameter ‘provider’)
Relevant source code snippets
Instead of pasting the source code of my actual functions app which is a bit more complex, I’ve managed to replicate the issue in a simpler form using the Visual Studio functions app template. Below are steps to replicate:
- Open Visual Studio 2019.
- Create a new empty functions app using Azure Functions v3 (.NET Core) and select Storage Emulator as the storage account.
- Once the project has been scaffolded, right-click on the project and add New Azure Function. Select Durable Functions Orchestration as the type.
- Update the Microsoft.NET.Sdk.Functions NuGet package to 3.0.2.
- Update the Microsoft.Azure.WebJobs.Extensions.DurableTask NuGet package to 2.1.0.
- If you try and build the project at this point, you’ll get errors since the types have changed. Update the function class with the correct types to resolve the build errors.
- Open host.json and replace the contents with
{ "version": "2.0", "extensions": { "durableTask": { "hubName": "%MyTaskHub%" } } }
. This snippet is taken directly from the documentation (link at the top of this issue). - Open local.settings.json and add
"MyTaskHub" : "samplehubname"
to the “Values” section. Again, this snippet is taken directly from the documentation. - Open the function class and update
[DurableClient]
to[DurableClient(TaskHub = "%MyTaskHub%")]
. - Debug the functions app and during startup, the exception described above is thrown.
Known workarounds
The only way I’ve managed to get it working is to manually make sure the host.json “hubName” matches the value of “MyTaskHub” in local.settings.json. You can verify this by changing the value of “hubName” in host.json to “samplehubname” after following the replication steps above. After doing so, debug the project and it should at least run correctly.
This workaround isn’t ideal as it means I would need to update the value everytime instead of the value coming from the appsettings.
App Details
- AzureFunctionsVersion: v3
- TargetFramework: netcoreapp3.0
- Microsoft.NET.Sdk.Functions: v3.0.2
- Microsoft.Azure.WebJobs.Extensions.DurableTask: v2.1.0
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 2
- Comments: 23 (5 by maintainers)
Commits related to this issue
- Fix TaskHub validation TaskHub validation needs to occur after the TaskHub has been resolved. To achieve this, we resolve app settings earlier in the pipeline, as well as waiting to validate the Task... — committed to Azure/azure-functions-durable-extension by deleted user 5 years ago
- Fix #1122 Improved slot recognition and "development environment" recognition — committed to salv85/azure-functions-durable-extension by deleted user 4 years ago
If anyone is looking for a workaround before this is released, I’ve had luck setting the hub name using
AzureFunctionsJobHost__extensions__durableTask__hubName
in my app settings (and removing it entirely from host.json). I haven’t tested with local.settings.json yet.is it possible to have this prioritized and hot fixed? this is convoluting our entire CI/CD pipeline because we are creating our storage accounts on the fly and injecting the connection strings into the deployparams using ARM expressions. We’ve been waiting two weeks for this fix and things are still broken.
Thanks
Upgrading to 2.1.1 fixed this issue for me. Thanks guys!
@ConnorMcMahon yes, 2.1.1. I put the taskhub name in the slot’s app-settings and in an AppConfig service and then used the
DurableClientAttribute
’sTaskHub
property andextensions.durableTask.hubName
in host.json. I even setAzureFunctionsJobHost__extensions__durableTask__hubName
in the slot’s app-settings, to no avail. I also tried putting the name itself in the host.json, instead of using a variable (taskhubnameppe
, instead of%TaskHubName%
)It works on my local machine, it fails when deployed.
Update: I checked the deployed version of Microsoft.Azure.WebJobs.Extensions.DurableTask.dll and it is the same 2.1.1 I see on my machine. The stack trace confirms that the function app is loading the right version
{"assembly":"Microsoft.Azure.WebJobs.Extensions.DurableTask, Version=2.0.0.0, Culture=neutral, PublicKeyToken=014045d636e89289","fileName":"d:\\a\\r1\\a\\azure-functions-durable-extension\\src\\WebJobs.Extensions.DurableTask\\Options\\DurableTaskOptions.cs","method":"Microsoft.Azure.WebJobs.Extensions.DurableTask.DurableTaskOptions.Validate","level":0,"line":217}
Anyone can submit a PR. By chance did you try to push your changes to a local branch you created on this repo? That might explain the 403. The correct way to submit a PR is to fork this repo into your own GitHub account, make changes there, and then submit the PR from your fork. We’d be happy to review your proposed changes. 😃
This is very high in our priority list. I’ll see about when we can get a fix released, though it may be tricky due to the holiday schedule.
We’ve had this issue on AzureFunctionsVersion v2 as well