INameResolver for Queue Trigger in Azure Function V4

[ranouf]

Hi,

I would like to use the INameResolver for queue trigger like it's available in Azure WebJob. I know it was not available in the past, but is it plan to add for Azure Function V4? Is there a workaround to be able to use it?

here is the code used for Azure WebJob:

 public class TriggerNameResolver : INameResolver
    {
        private readonly IConfiguration _configuration;
        private readonly MessagerSettings _messagerSettings;

        public TriggerNameResolver(
            IConfiguration configuration,
            IOptions<MessagerSettings> messagerSettings
        )
        {
            _configuration = configuration;
            _messagerSettings = messagerSettings.Value;
        }

        public string Resolve(string name)
        {
            if (name.Contains(':'))
            {
                return _configuration[name].ToString();
            }
            return (_messagerSettings.QueueName + name).ToLower();
        }
    }

Thanks for your help

[v-bbalaiagar]

Hi @pragnagopa , Can we consider this issue as a feature request

[pragnagopa]

Tagging @fabiocav for triage.

[theo-albers]

Yes please, because it doesn't seem to be available. I would like to use IConfiguration with Azure App Service to inject configuration in a more flexible manner.

[bretthacker]

Is there an update on this? I'm trying it with a dotnet-isolated function even but the functions (and their queue attributes) seem to fire before my INameResolver fires.

[JohnWilson-PandSD]

There is another conversation going on about this over here: https://github.com/Azure/azure-functions-dotnet-worker/issues/393 - I've run into the same issue, and given that .NET 8 is forcing a move to the isolated process model, it would be nice to get it resolved ;)

[davcarrier]

Is there any update on this? It's a blocker for us to move to the isolated model

[theo-albers]

What works for us: setup IConfiguration, use a connection string name that maps to an IConfiguration value. We pass a tenant ID via the message. So we can't switch service bus connection dynamically, but we can:

• read the service bus connection from config
• setup a tenant context via middleware to execute the trigger for a tenant.

It looks like the isolated model has the service bus listener in the host and the trigger is being executed in the isolated process. That's why the old namereolver solution no longer works.

I really don't understand why service bus connection switching wasn't supported from the start since multi tenancy, tenant isolation is what cloud is all about.