azure-cli: Deployment of zip fails if run after creating functionapp.
This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az functionapp deployment source config-zip
Errors:
HTTPSConnectionPool(host='dev-XXXXXXXXX.scm.azurewebsites.net', port=443): Read timed out. (read timeout=3)
Traceback (most recent call last):
python3.6/site-packages/urllib3/connectionpool.py, ln 426, in _make_request
six.raise_from(e, None)
<string>, ln 3, in raise_from
python3.6/site-packages/urllib3/connectionpool.py, ln 421, in _make_request
httplib_response = conn.getresponse()
lib/python3.6/http/client.py, ln 1354, in getresponse
response.begin()
...
socket.timeout: The read operation timed out
python3.6/site-packages/requests/adapters.py, ln 529, in send
raise ReadTimeout(e, request=request)
requests.exceptions.ReadTimeout: HTTPSConnectionPool(host='dev-XXXXXXXXX.scm.azurewebsites.net', port=443): Read timed out. (read timeout=3)
To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.
- Put any pre-requisite steps here…
az functionapp deployment source config-zip --src {} -g {} -n {}
Expected Behavior
The zip deploys successfully.
Environment Summary
Linux-5.15.0-1022-azure-x86_64-with-debian-bullseye-sid
Python 3.6.10
Installer: DEB
azure-cli 2.19.0 *
Additional Context
If the same code is used to deploy to an existing function app, after a sufficient delay, it is successful. I think that this is timing related, so if it is possible for me to determine that a functionapp is ready to deploy to after creation, I would be happy to add code that manages this. However, I feel it would be better for the deployment code itself to wait a sufficient amount of time, rather than timing out.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 35 (17 by maintainers)
Thanks @mr-davidc for reporting it. We have identified the issue and will have the fix out in one of the first releases next year.
We have identified the issue and we are in process of prioritizing the fix.
I am trying both locally and on an Azure VM and they behave identically. I’ll try the longer timeout and report back.