Inconsistent behavior when managing Functions Host and App Service settings via Rest API

Hi,

This ticket was migrated from https://github.com/Azure/azure-functions-host/issues/11477 by request of @jviau. I will shortly summarize the problem here but feel free to read the original ticket for further details.

We are using a Linux App Service with Azure Functions running on it. We experienced a problem with a function not starting after the Functions Host version was upgraded (by the App Service team), and tracked this down into a security enhancement that required actions on our part.

Those actions were to use the Rest API to add a new setting to the App Service, and adjust our function creation call so that "function.json" file no longer contains sensitive secrets.

During this process we discovered that the Rest API does not work in an entirely logical fashion. What we do is first call [this method](https://learn.microsoft.com/en-us/rest/api/appservice/web-apps/update-application-settings?view=rest-appservice-2025-03-01&tabs=HTTP) to add a setting which later should become an environment variable for the Functions Host container. We then call [this](https://learn.microsoft.com/en-us/rest/api/appservice/web-apps/restart?view=rest-appservice-2025-03-01) to perform a synchronous "hard restart" of the App Service so that this new setting would become effective. Finally, we call [this](https://learn.microsoft.com/en-us/rest/api/appservice/web-apps/create-function?view=rest-appservice-2025-03-01) to create a function instance.

What we noticed is that the restart is not synchronous, despite the query parameters. Instead, it returns instantly, and the new function instance gets added right away, and the Functions Host performs an "internal restart" to load it. As a consequence this function instance does not start correctly because the setting it depends to is not yet available in the Functions Host container.

Why isn't the restart synchronous despite us providing the flag?

The call is made with NodeJS, using "@azure/arm-appservice" package version 17.0.0. This is a "generated SDK" for the NodeJS and thus I do not believe it to be a bug in the library itself.

Review the linked App Service REST operations for update-application-settings, restart, and create-function, then reproduce the documented sequence with @azure/arm-appservice 17.0.0 on a Linux App Service. Determine whether the restart request is expected to block and identify whether the behavior belongs to the generated SDK, the REST API, or the Functions Host; done means the behavior and required fix or documentation are established.

Written by the indexing model from the issue text.