vscode-azurefunctions
vscode-azurefunctions copied to clipboard
microsoft
Investigate ECONNRESET issue during "zipdeploy" call
Creating this issue as a catch-all for the "ECONNRESET" errors being reported specifically for the "zipdeloy" call. Usually a retry helps fix these errors, but it's possible our retry logic isn't working in this case because it's using a stream to send the zip file and I don't know if we handle restarting the stream on a retry.
It's also possible this could be caused by especially large zip files or especially slow internet.
Update April 13, 2022
The 1.66.0 VS Code update resulted in many users encountering ECONNRESET and 400 Bad Request errors when attempting to deploy their app. A fix has been released in version v1.6.2 of the extension. (comment)
just tried 1.6, and it's still the case for me that any version 1.3.0 or greater fails with this error, so I'll stick to the version just before 1.3.0, 1.2.1 where it works just fine.
I'm experiencing the same (I think) issues as @blomm - deploy of TypeScript Azure Functions project does not work from VS Code with v1.6 (ECONNRESET), works fine after downgrading to 1.2.1. Let me know if I could provide more info for the investigation
Had the exact same issue and downgrading the Azure functions extension resolved it. Note that I had a whole bunch of issues deploying via Github actions which is why I moved to doing the deployment through the extension instead. My function app is quite large (~10 individual functions).
The only change between v1.3.0 and v1.2.1 that I can see that would impact the ECONNRESET error is right here: https://github.com/microsoft/vscode-azuretools/commit/c6d587c7dbef79f3e00bafcf0e9a096d4d1d97eb#diff-193b27d62e4fbda3d563009fed5ec6761a05f73558d94b39fab63ae948c679eaR38
Between versions, we updated the vscode-azureappservice package from 0.72.1 to 0.73.0:
https://github.com/microsoft/vscode-azurefunctions/commit/5de6996b6917f6a456b06f922a63e2f6611af43c#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519R1130
The only change between those versions is updating the ui package: https://github.com/microsoft/vscode-azuretools/commit/9c15e6fc45179181b2b46901b2eb0b42e09f8e1a
Where we updated ms-rest-js
https://github.com/microsoft/vscode-azuretools/commit/c6d587c7dbef79f3e00bafcf0e9a096d4d1d97eb
So seems like we should start our investigation from there. 🔍
Ran into the issue yesterday after updating VS Code (I update frequently, so that it worked before should not have been caused by using some outdated version). Suddenly all TypeScript deployments got stuck just after the zip is created (Zip package size: X MB in the output) and eventually time out with ECONNRESET error for url https://xxx.scm.azurewebsites.net/api/zipdeploy?isAsync=true&author=VS Code.
I've tried everything from reinstalling Core Tools, rebooting, using different app service plan and waiting several hours (as I've read ECONNRESET in Azure is usually only transient issue), but only thing that makes this work again is downgrading to the previously mentioned year old release 1.2.1, where the zip creation is immediately followed by output Fetching changes. and eventually successfully completes.
Same issue here. After today's update of VSCode (March 2022) the Logic Apps deployment doesn't work anymore.
can we treat this issue seriously yet @ejizba? I'm still scared to perform any upgrades around the Azure Functions extension, sticking to 1.2.1
One more problem with the v1.2.1 workaround - turns out this does not accept ~4 as a functions target version, only ~1 - ~3, which effectively constraints to use manual CLI publish if you need to target ~4.
I've captured the problematic request and did a little comparison. It seems, that while the old 1.2.1 version provides Content-Length and the actual file content, the 1.6.1 request issues a chunk request, without any body - maybe that's where the server hangs waiting for the first chunk. The non-working request does not make it into Kudu traces at /api/vfs/LogFiles/kudu/.
Based on the number of comments within several hours, I'm guessing this is a new issue related to the release of VS Code 1.66. Does it reproduce if you use the previous version of VS Code? I checked the release notes and the only thing I saw that could be related is they bumped from Node.js v14 to v16.
I'm not on this particular team anymore, but hopefully @nturinski @alexweininger or @bwateratmsft could take a look relatively soon.
@sven5 the logic apps extension is a different extension/team - you'll have to follow up with them separately.
Users created an issue on VS Code: https://github.com/microsoft/vscode/issues/146470
I'm able to reproduce the issue on 1.67.0-insider.
VS Code version details
Version: 1.67.0-insider (Universal)
Commit: 909602cf04e0fa42528d692676d0d4e15e67bba2
Date: 2022-03-31T11:04:00.413Z
Electron: 17.2.0
Chromium: 98.0.4758.109
Node.js: 16.13.0
V8: 9.8.177.11-electron.0
OS: Darwin x64 21.4.0
I agree that this seems to be related to the 1.66.0 VS Code release due to the timing of the issue reports. Further backed up by comments saying zip deploy worked again after reverting to 1.65.2.
As for the issue itself, I'm not immediately sure how upgrading from Node.JS v14 to v16 could break zip deploy, but we'll investigate. 🕵️
Also having this issue.
Could be from VSCode Azure SDK for Node.js - App Service Tools.
Which appears to silently failing unit tests? I'm not sure, but those look like errors from the log, yet reporting successful test cases. Which maybe why it wasn't caught pre-release.
Should an issue be opened on the Azure SDK for Node.js repo?
An alternative if someone is looking for another option (using Azure Functions Core Tools (4.x or later) and Azure CLI (2.4 or later)):
#!/bin/bash
# $1 => folder or file name to be zipped
# $2 => function app name
# $3 => resource group name
echo "Starting deployment..."
ZIP_NAME=`date "+%Y%m%d%H%M%S.zip"`
echo "Changing directory to $1/"
cd $1
echo "Creating zip package"
zip -r ${ZIP_NAME} . --exclude @.funcignore --exclude .funcignore > /dev/null 2>&1
echo "Zip created"
az functionapp deployment source config-zip -n $2 -g $3 --src ${ZIP_NAME}
rm ${ZIP_NAME}
echo "Zip removed"
open to suggestions
Same issue, VS Code updated to March 2022 release and suddenly deployments stopped. All I see in logs was creating a zip file and then after long wait an error to call zipdeploy API. Tried all options but eventually downgrading to 1.65 helped.
Not sure what is the root issue, but there is something breaking between the two releases when it comes to Azure functions.
This issue has been plaguing me for days but downgrading VS Code to 1.65.2 solved it instantly.
I can't believe it -- I search internet -- and you kind people are right -- the new update broke all this -- I couldnt even get LocalGit to work right . Thanks for the downgrade suggestion - its working again for me
Until a fix is released in VS Code stable (hopefully the next major release), here are some options:
- Wait for the fix to come in VS Code Insiders
- Deploy via Azure CLI
- Downgrade your Azure Functions extension version to
1.2.1(Feb 08, 2021), we used a different zip deploy method which seems to be working still. Note: it might not work in environments like WSL or Codespaces, which is why we changed our deploy in1.3.0(Mar 15, 2021). - Downgrade to the VS Code February 2022 release, where zip deploy is working as discussed and confirmed above.
Here's some information on the bug we suspect is causing the issue with zip deploy.
We suspect that it was a regression in the libuv library caused by libuv/libuv@ce15b84, which was included in Node.JS 16.13.0.
See this issue, and specifically this comment for more information.
Thank god I found this thread. I was getting mad because my deploys sudenly stopped working. Indeed, getting back to version 1.2.1 allowed me to deploy my azure functions again. Please, fix this! I like toi keep mi VS Extensions up to date
Downgraded vs code, by simply running the installer from here: https://code.visualstudio.com/updates/v1_65
Downgraded vs code, by simply running the installer from here: https://code.visualstudio.com/updates/v1_65
A fix of the extensión or VS Code version will be a better solution :). But for now, any of this options works. Thanks
@paladin2005 too bad, I just downgraded, and it fixed it for me as well. Will try upgrading now :)
They updated vscode and it is fixed for me now
Not sure, as current version (including the latest Insider build) of VS code doesn't work. Only option for now is to downgrade VS Code to 1.65.x.
They updated vscode and it is fixed for me now Not sure, as current version (including the latest Insider build) of VS code doesn't work. Only option for now is to downgrade VS Code to 1.65.x.
I don't know why to downvote me, I am telling you I had that problem too, VScode updated and start working, and my client was waiting for some changes. in my case, I couldn't deploy the "publish" folder in my backend and the "dist" folder on my frontend, it was getting stuck when creating the zip file to publish. I saw an update and tried again and it worked again. Was this update: Vscode 1.66.1
They updated vscode and it is fixed for me now Not sure, as current version (including the latest Insider build) of VS code doesn't work. Only option for now is to downgrade VS Code to 1.65.x.
I don't know why to downvote me, I am telling you I had that problem too, VScode updated and start working, and my client was waiting for some changes. in my case, I couldn't deploy the "publish" folder in my backend and the "dist" folder on my frontend, it was getting stuck when creating the zip file to publish. I saw an update and tried again and it worked again. Was this update: Vscode 1.66.1
It didn't work for me:
VS Code: 1.66.1 Azure App Service: 0.23.1 Azure Functions: 1.6.1
It worked was to downgrade to VS Code 1.65.2
@paladin2005 Understood. There seems to be some misunderstanding due to language gaps perhaps.
Do you want to say that: your VSCode also got updated to 1.66 and you started working on some changes which client asked. But when you tried to upload, it failed.
If that is the part with "update", you are absolutely correct. Everyone started facing the problem with this update to version 1.66.
Only solution which worked for others (and most likely for you also) is to downgrade to 1.65 release of VSCode.