Creating multiple functions before restarting the function host

[anttikes]

What problem would the feature you're requesting solve? Please describe.

We have a scenario where we need to create function instances programmatically. The actual code that the function runs is deployed from an Azure DevOps via the zip deployment option but this package does not contain any "function.json" files nor "main.js" or anything else either. It just contains the code that the function instances execute.

What we do, then, is that we have a separate web application in which the end user manages the settings (mainly, connection strings and AMQP queue names) that the function instances are supposed to use. Upon saving changes, the web application tests the settings by sending and reading a message from two queues, and then creates a pair of function instances one for each queue.

Now, we can create these function instances just fine by invoking the PUT /admin/functions/<function name> endpoint. We send in the content of "function.json" as the body. The function is created, and the function host restarts.

Describe the solution you'd like

The problem we have is that the function host wants to restart after each function creation. This is rather tedious for us because the functions operate in pairs; one can't really operate without the other. So we create one instance, wait for the host to restart, and then create the other, and then wait for the host to restart again.

What we would like, instead, is the ability to suppress the restart logic, create two function instances, and then resume the restart logic so the function host would only restart once.

Describe alternatives you've considered

We considered an alternative where we would generate the "function.json" files dynamically in a separate Azure DevOps pipeline that reads the settings directly from the place we store them. We would have two pipelines, one which deploys the code that the functions are expected to run, and another which creates a "package" of "function.json" files that represent the functions themselves. This turned out to be more than just a little tedious as doing multiple zip deployments to a single function host caused existing files to get overridden.

We have also considered an approach where both the code the functions as supposed to use and the "function.json" files are created by the same pipeline but unfortunately the settings may get updated quite often. This means the pipeline would also run and deploy artifacts quite often, leading to a lot of downtime in the function host itself.