az functionapp deployment using a zip with a flex app in a private network fails never gets pass health check

[Joelith]

Describe the bug

If you have a flex app within a private network and blocked to only allow networking via a front door (eg: to make it secure) the deployment will never pass as you cannot bypass the health check.

If I run this command

az functionapp deployment source config-zip --name <name>--resource-group <group> --src function.zip --timeout 30 --debug --verbose

I can see that the function deploys correctly but ends up stuck doing a health check.

urllib3.connectionpool: https://<func name>.azurewebsites.net:443 "GET /admin/host/status HTTP/1.1" 403 1892
urllib3.connectionpool: Starting new HTTPS connection (1): <func name>.azurewebsites.net:443

This health check will never pass as I've set up the function to Deny any request that doesn't come from the Front Door. Using func azure functionapp publish... approach doesn't have this error as it doesn't do a health check, but this approach does not work for flex consumption apps.

The --timeout as discussed in the documentation doesn't do anything (or doesn't apply to the health check) and the command will just run indefinitely.

Is there a workaround as my build scripts will now never finish. Ideally a --ignore-health-check could be added, and leave it up to me to determine if the application is healthy

Related command

az functionapp deployment source config-zip

Errors

Does not produce an error - it just never gets past the health check

Issue script & Debug output

See above

Expected behavior

The health check should either timeout, respect the --timeout or allow me to bypass.

Environment Summary

azure-cli 2.69.0

core 2.69.0
telemetry 1.1.0

Extensions:
account 0.2.5
aks-preview 13.0.0b6
containerapp 1.1.0b3
front-door 1.2.0
webpubsub 1.7.0

Dependencies:
msal 1.31.2b1
azure-mgmt-resource 23.1.1

Python (Darwin) 3.12.9 (main, Feb 4 2025, 14:38:38) [Clang 16.0.0 (clang-1600.0.26.6)]

Legal docs and information: aka.ms/AzureCliLegal

Additional context

No response

[yonzhan]

Thank you for opening this issue, we will look into it.

[microsoft-github-policy-service]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @AnatoliB, @Francisco-Gamino, @shreyabatra4.

[Pabzt]

We face the same issue. Forces us to build hacks into our deployment pipeline :(

[Joelith]

Same - we've had to add a 60 second timeout and hope that it actually deployed (rather than failed due to an actual network timeout during deployment). I thought the primary use case for flex consumption was to give us consumption functions with private networking, so this seems like a massive oversight?

[Joelith]

Is there any update on this - we have to put arbitary timeouts into our build processes. But sometimes Azure legitimately may take 60 seconds to deploy so we are cancelling the deployment too early. I just want it to not check that the service is accessible (as it won't be from my network).