Azure-functions-host: Specifying host.json options on a per function level

[APIWT]

Is your question related to a specific version? If so, please specify:

v3 runtime

What language does your question apply to? (e.g. C#, JavaScript, Java, All)

C#

Question

I am trying to specify queues -> batchSize on a per function basis. It seems like I should be able to do this. Right now, it looks like my only option is to create a separate Azure Functions instance/project for each function that I want to take a different configuration.

[benbelow]

I'm coming to a similar conclusion with concurrency settings in Durable Functions. My application has ended up being comprised of multiple functions apps with subtly different settings, and it would be nice if possible to change settings per function to allow more of these to be consolidated into one app.

[Matthewsre]

I have several functions in a project that we deploy with Azure DevOps. We have to limit concurrency for only one of our functions, but now we need to separate it out, create an additional Function App, separate release, etc. It would be really nice it we could configure some options either on the trigger attribute or specify a separate attribute on the method.

[jernejc]

Same scenario here. Need to limit Service Bus "maxConcurrentCalls" per function. This also increases cost with Premium Service Plan and generally more cold starts. Currently now way to do this right ?

[cyberpion-yotam]

Same issue here with Azure Storage Queue. Wanted multiple maxDequeueCount values for different functions and queues in the app.

[AartBluestoke]

My recent use case here was log sampling ratio. I've an app with multiple functions. one is common, and is sampled. others are rare(once per day).

We already admit that logging has more granular scope than 'app' by allowing different log levels per namespace, but it would be great to say 'these functions are important, don't sample them', 'these functions are not important, only trace 1 message per minute to ensure nothing wierd is happening'

Azure support currently suggests "just deploy them to different apps if they have different needs" .
The effort to deploy and mange a complete new app (identy, secrets, deployment pipeline complexity,....) just to set up a single different log parameter (or queue concurrency) does not seem to be a deliberate design decision.