Aws Toolkit running SAM (Node/Python/Other langs), timeout parameter weird behaviour

[MFlyer]

Problem

I have multiple local environments with a template having

Globals: Function: Timeout: 120

Starting from aws toolkit 1.97.0 the default timeout had a value of 1234 millis and, at the same time, it seems not able to honor the yaml template defined Timeout (that's in seconds, not millis)

System info

• OS: Ubuntu 20.4
• Visual Studio Code version: 1.84.0
• AWS Toolkit version: 1.97.0

Current workaround

Manually edit aws toolkit default timeout for lambda

[justinmk3]

That means this code is failing to update your settings: https://github.com/aws/aws-toolkit-vscode/blob/6864975281e660de9ea23fda9fe0d23b6dc13e16/src/shared/settings.ts#L104-L110

Can you provide the Toolkit logs (check that private info is removed)?

1. In VSCode settings, ensure that "aws log level" is "debug".
2. Perform the steps to reproduce the issue.
3. Use the AWS: View Toolkit Logs command to get the logs.

[MFlyer]

Hi @justinmk3 , providing required info and some context about env used to provide you with logs:

• Python 3.8 Runtime,
• No samconfig.toml file in the app folder
• template.yaml has a Globals -> Function -> Timeout with 30 (seconds)
• Changing Timeout to 30000 (assuming millis) doesn't solve, it's the aws toolkit ignoring template.yaml timeout at all

Log file attached

Question of the day: why that "random" 1234 millis as a default, having something like 60000/90000 millis or the aws lambda default timeout should be more logic, don't you agree?! aws_toolkit-logs.txt

[justinmk3]

having something like 60000/90000 millis or the aws lambda default timeout should be more logic, don't you agree?!

For local run/debug, the user may take minutes or longer while stepping through breakpoints. So the template.yaml timeout is ignored because debugging can pause execution at any time.

why that "random" 1234 millis as a default?

That random value is only temporarily written to check that reading/writing vscode settings actually works. I'm wondering if (or why) Toolkit failed to remove that random value.

• In your logs I don't see a settings message, so I guess the failed write is no longer happening, i.e. the value is not forced to 1234, correct?
• When reproducing the issue, did you first delete the aws.samcli.lambdaTimeout setting from your vscode settings?

[MFlyer]

I updated the aws toolkit yesterday morning and I started seeing the timeout, as soon as I understood that the issue was with the default 1234 millis I changed it to an acceptable value. Currently I'm not able to delete that vscode setting, it seems mandatory, I only found it once after the aws toolkit update and I don't remember the previous value of the field

[justinmk3]

not able to delete that vscode setting, it seems mandatory

The vscode settings UI doesn't really make it easy to "delete" a setting. Instead you would need to edit the settings.json:

1. run Preferences: Open User Settings (JSON) vscode command
2. search for lambdaTimeout
3. delete that line in the JSON file

Then restart vscode. If the problem happens again, sharing the AWS Toolkit logs here would be helpful!

[MFlyer]

Hi @justinmk3 , not able to reproduce it anymore:

• deleted lambdaTimeout property from JSON file
• the aws toolkit still has a timeout equal to 90000 millis (it states it's coming from my workspace settings, but I don't have it in the workspace settings?!)
• uninstalling the aws toolkit extension and installing it again still has the previous added "right" timeout
• no more able to reproduce that weird behaviour

[justinmk3]

@MFlyer thank you so much for troubleshooting this. We will try to think of an improvement to the logic here.

[justinmk3]

https://github.com/aws/aws-toolkit-vscode/pull/4054 was included in AWS Toolkit 2.0.0