Bind to QueueTrigger using HostId
I would like to bind to a queue with a name including the function runtime host name (referenced as HostId in some doc). %AzureFunctionsWebHost__hostid% works when that value is set explicitly, but I cannot access it when the default HostId is used.
Derek Price
shared this idea
This feels a bit problematic – I’m not quite sure what is attempted here. It sounds like you want one queue per instance of the host, but hosts can be created and disposed at anytime so wary of allowing any dependencies on binding to an instance of the host. Feel free to add more context into the scenario and what is hope to be achieved.
-
Jeff
1 comment
-
Derek Price
commented
It's been nearly 6 months since I posted this, but I'll do my best to recall the issue:
Several development environments and our staging environment share one storage container. To avoid collisions, I use a binding like this:
{
"type": "queueTrigger",
"direction": "in",
"name": "successTrigger",
"queueName": "azure-webjobs-success-%AzureFunctionsWebHost:hostid%"
},This works fine when I set the host ID explicitly, which I do for all the instances in our staging and production environments, but fails for the default hostid provided by the development environments.
Incidentally, we do have a non-standard deployment. We are running our instances via the functions runtime docker container in our own AKS environment. The function runtime was already automatically giving each of our pods separate queues with names based on hostid for blob triggers, so I ended up having to supply a hostid explicitly in our production and staging environments to avoid having each one restart with its own, fresh, blob trigger queue.
From there, it just seemed like a natural leap to use hostid in the names of our other triggers to avoid collision. In the dev environments, we only ever have one hostid, so it would make our lives a little easier to make it accessible when it isn't set explicitly, but the workaround is fairly simple - we just set it.