SAM invoke fails when trying to debug

Sorry guys but the issue I previously reported in #1666 is back with AWS Tookit v1.25. When I revert to v1.24 everything works again.

Essentially when trying to debug an AWS Lambda in python, the debugger can no longer attach to the process. It’s complaining that sam can’t start the application locally.

My aws_toolkit_log

2021-05-21 10:49:46 [ERROR]: log level: info
2021-05-21 10:49:46 [INFO]: Retrieving AWS endpoint data
2021-05-21 10:49:46 [INFO]: OS:  Windows_NT x64 10.0.19042
2021-05-21 10:49:46 [INFO]: Visual Studio Code Extension Host Version:  1.56.2
2021-05-21 10:49:46 [INFO]: AWS Toolkit Version:  1.25.0
2021-05-21 10:50:10 [INFO]: Python CodeLens Provider is activating the python extension
2021-05-21 10:50:11 [INFO]: Python CodeLens Provider is activating the python extension
2021-05-21 10:50:18 [INFO]: Preparing to debug locally: Lambda "update_edgar_series.lambda_handler"
2021-05-21 10:50:18 [INFO]: Building SAM application...
2021-05-21 10:50:18 [INFO]: Running command: (not started) [C:\Program Files\Amazon\AWSSAMCLI\bin\sam.cmd build --build-dir C:\Users\efrem\AppData\Local\Temp\aws-toolkit-vscode\vsctkWvToTZ\output --template C:/Users/efrem/source/repos/GitHub/AWS-Code/production/applications/fundamental_data/fundamental-data-etl/app___vsctk___template.yaml --manifest C:\Users\efrem\AppData\Local\Temp\aws-toolkit-vscode\vsctkWvToTZ\debug-requirements.txt]
2021-05-21 10:50:18 [INFO]: Running: (not started) [C:\Program Files\Amazon\AWSSAMCLI\bin\sam.cmd build --build-dir C:\Users\efrem\AppData\Local\Temp\aws-toolkit-vscode\vsctkWvToTZ\output --template C:/Users/efrem/source/repos/GitHub/AWS-Code/production/applications/fundamental_data/fundamental-data-etl/app___vsctk___template.yaml --manifest C:\Users\efrem\AppData\Local\Temp\aws-toolkit-vscode\vsctkWvToTZ\debug-requirements.txt]
2021-05-21 10:52:35 [INFO]: Build complete.
2021-05-21 10:52:35 [INFO]: Starting SAM application locally
2021-05-21 10:52:37 [INFO]: AWS.running.command
2021-05-21 10:52:37 [INFO]: Running: (not started) [C:\Program Files\Amazon\AWSSAMCLI\bin\sam.cmd local invoke UpdateEDGARSeriesFunction --template C:\Users\efrem\AppData\Local\Temp\aws-toolkit-vscode\vsctkWvToTZ\output\template.yaml --event C:\Users\efrem\AppData\Local\Temp\aws-toolkit-vscode\vsctkWvToTZ\event.json --env-vars C:\Users\efrem\AppData\Local\Temp\aws-toolkit-vscode\vsctkWvToTZ\env-vars.json -d 5858 --debugger-path c:\Users\efrem\.vscode\extensions\amazonwebservices.aws-toolkit-vscode-1.25.0\resources\debugger --debug-args /tmp/lambci_debug_files/py_debug_wrapper.py --listen 0.0.0.0:5858 --wait-for-client --log-to-stderr]
2021-05-21 10:52:37 [ERROR]: Timeout while waiting for command: "sam local invoke"
2021-05-21 10:52:37 [ERROR]: Failed to run SAM application locally: Timeout while waiting for command: "sam local invoke"

I’m running Visual Studio Code on Windows 10 20H2 64 bit. Running Docker desktop v3.3.3(64133) using WSL2 backend Installed sam version is 1.23

SAM will successfully build this lambda and it runs successfully once deployed. Just can’t debug it.

Not sure what other info I can give you. Let me know.

Thanks

[efremsternbach]

Tried the vsix and there was no change from v1.25. Local invocation of process still fails.

I’m obviously not intimately knowledgeable about the extension. However the fact that it works quite reliably with v1.24 but never with v1.25 and above suggests to me that the timeout is not the issue. The same version of sam is being used by all extension versions. I would guess that there is some other issue preventing the local process from starting.

Unfortunately don’t have a large amount of time the apply to this at the moment since if needed I can stick with v1.24. This software is a huge help to me in my work so I’ll try to help out if I can. Thanks for your help.

[JadenSimon]

Glad to help! Ideally the extension should be ‘smart’ and only run the timer down when SAM CLI stops communicating but this is currently unimplemented for the build step. Until we get around to doing that, surfacing better information about the timeout seems to be the way go.