Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: Unable to debug typescript sam app via VScode breakpoints #6658

Closed
DawitAskabe opened this issue Feb 6, 2024 · 5 comments
Closed

Bug: Unable to debug typescript sam app via VScode breakpoints #6658

DawitAskabe opened this issue Feb 6, 2024 · 5 comments
Labels
area/debugging blocked/close-if-inactive Blocked for >14 days with no response, will be closed if still inactive after 7 days type/question

Comments

@DawitAskabe
Copy link

Description:

We are trying to debug lambdas via VScode by calling the services locally from postman.
VScode does not remain open or attached for us to be able to break or debug.

Steps to reproduce:

Currently our debug workflow is to run :
"start": "npm run build & sam local start-api",
This mounts all the lambdas as follows

...                                                                                                                      
Mounting TodoPut at http://127.0.0.1:3000/todo[PUT, OPTIONS] 
...
You can now browse to the above endpoints to invoke your functions. You do not need to restart/reload SAM CLI while working on your functions, changes will be reflected instantly/automatically. If you used sam build      
before running local commands, you will need to re-run sam build for the changes to be picked up. You only need to restart SAM CLI if you update your AWS SAM template                                                       
 * Tip: There are .env or .flaskenv files present. Do "pip install python-dotenv" to use them.
2024-02-06 13:28:12 WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on http://127.0.0.1:3000
2024-02-06 13:28:12 Press CTRL+C to quit
.                                                                                                                            

Then we use postman to make API call to one of these lambdas. (the lambdas execute and finish fine without stopping at breakpoints)

I have spent countless hours to get vscode to stop at breakpoints. This is my current configuration in launch.json

{
    "configurations": [
        {
            "name": "Attach to SAM Local API",
            "type": "node",
            "request": "attach",
            "address": "localhost",
            "restart": true,
            "port": 3000,
            "localRoot": "${workspaceRoot}",
            "remoteRoot": "/var/task",
            "outFiles": [
                "${workspaceRoot}/dist/**/*.js"
            ],
            "sourceMaps": true
        },
    ]
}

The above is what i have currently but i attempted countless variations.
I attempted to run sam using
sam local start-api -d 5858 -p 3000 --debugger-path "$(pwd)/.vscode" and setting 5858 as port in launch.json without luck.

our build step generate maps for each lambda and put it in dist folder in this structure.
dist
├── todo-put
│ ├── application.yml
│ ├── index.js
│ └── index.js.map
└── todo-tasks-get
├── application.yml
├── index.js
└── index.js.map

Observed result:

Following the above setups; once sam local start-api is done and api paths are mounted; if i try to run the debugger it makes some get calls and fails...(these are some random api calls i have no idea about).

2024-02-06 14:07:50 Press CTRL+C to quit
2024-02-06 14:07:54 127.0.0.1 - - [06/Feb/2024 14:07:54] "GET /json/version HTTP/1.1" 403 -
2024-02-06 14:07:54 127.0.0.1 - - [06/Feb/2024 14:07:54] "GET /json/list HTTP/1.1" 403 -
2024-02-06 14:07:57 127.0.0.1 - - [06/Feb/2024 14:07:57] "GET /json/version HTTP/1.1" 403 -
2024-02-06 14:07:57 127.0.0.1 - - [06/Feb/2024 14:07:57] "GET /json/list HTTP/1.1" 403 -
2024-02-06 14:08:00 127.0.0.1 - - [06/Feb/2024 14:08:00] "GET /json/version HTTP/1.1" 403 -
2024-02-06 14:08:00 127.0.0.1 - - [06/Feb/2024 14:08:00] "GET /json/list HTTP/1.1" 403 -
2024-02-06 14:08:04 127.0.0.1 - - [06/Feb/2024 14:08:04] "GET /json/version HTTP/1.1" 403 -
2024-02-06 14:08:04 127.0.0.1 - - [06/Feb/2024 14:08:04] "GET /json/list HTTP/1.1" 403 -

image

Expected result:

vscode should wait for api calls to happen and stop at breakpoint in the invoked lambda.
When the api call is made from postman, sam invokes the index.handler and mounts it in the docker container to run (from what i can gather from the output bellow). Vscode debugger should stop at breakpoint once the lambda is running in the container.
This is the sam output when calling a service from postman - finishes correctly

Invoking index.handler (nodejs18.x)                                                                                                                                                                                          
Local image is up-to-date                                                                                                                                                                                                    
Using local image: public.ecr.aws/lambda/nodejs:18-rapid-x86_64.                                                                                                                                                             
                                                                                                                                                                                                                             
Mounting /Users/d/Documents/workspace/project/dist/todo-put as /var/task:ro,delegated, inside runtime container                                                                                     
START RequestId: 5fc94672-5424-4347-b4f6-5e4f0139cc79 Version: $LATEST
2024-02-06T20:00:01.459Z        52222294672-2222-3333-b4f6-111111    INFO    User authenticated by authorizer as user@domain.com {"level":30,"time":170724901459,"pid":16,"hostname":"","awsRequestId":"1111","apiRequestId":"1111","x-correlation-id":"22222","msg":"User authenticated by authorizer as user@domain.com"}

END RequestId: id
REPORT RequestId: id  Init Duration: 1.89 ms  Duration: 3918.99 ms    Billed Duration: 3919 ms        Memory Size: 256 MB     Max Memory Used: 256 MB

2024-02-06 14:00:03 127.0.0.1 - - [06/Feb/2024 14:00:03] "PUT //todo HTTP/1.1" 200 -

Additional environment details (Ex: Windows, Mac, Amazon Linux etc)

  1. OS: mac
  2. sam --version:SAM CLI, version 1.100.0
  3. AWS region: us-east-2
{
  "version": "1.100.0",
  "system": {
    "python": "3.8.13",
    "os": "macOS-14.3-x86_64-i386-64bit"
  },
  "additional_dependencies": {
    "docker_engine": "25.0.2",
    "aws_cdk": "Not available",
    "terraform": "1.6.3"
  },
  "available_beta_feature_env_vars": [
    "SAM_CLI_BETA_FEATURES",
    "SAM_CLI_BETA_BUILD_PERFORMANCE",
    "SAM_CLI_BETA_TERRAFORM_SUPPORT",
    "SAM_CLI_BETA_RUST_CARGO_LAMBDA"
  ]
}

Add --debug flag to command you are running

@DawitAskabe DawitAskabe added the stage/needs-triage Automatically applied to new issues and PRs, indicating they haven't been looked at. label Feb 6, 2024
@DawitAskabe
Copy link
Author

TLDR version:
In this execution example from aws website

sam local start-api

Initializing the lambda functions containers.
Local image is up-to-date
Using local image: public.ecr.aws/lambda/python:3.9-rapid-x86_64.

Mounting /Users/.../sam-app/.aws-sam/build/HelloWorldFunction as /var/task:ro,delegated, inside runtime container
Containers Initialization is done.
Mounting HelloWorldFunction at http://127.0.0.1:3000/hello [GET]
You can now browse to the above endpoints to invoke your functions. You do not need to restart/reload SAM CLI while working on your functions, changes will be reflected instantly/automatically. If you used sam build before running local commands, you will need to re-run sam build for the changes to be picked up. You only need to restart SAM CLI if you update your AWS SAM template
2023-04-12 14:41:05 WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on http://127.0.0.1:3000

Since the lambda is running in a container at time of execution (api call); what is the proper vscode configuration for the debugger to be notified that 'we mounted a lambda in a container for execution...and that it needs to break in typescript code. I know the js and map file are deployed correctly in `/var/task folder

image

@hawflau
Copy link
Contributor

hawflau commented Feb 13, 2024

Hey @DawitAskabe, thanks for raising the issue. As you've mentioned, the Lambda Function is running within a container. So I don't think the "node" type would work. You can install AWS Toolkit in VS Code. It provides the "aws-sam" type in launch config so that you can use it to debug your SAM application. For details, please see https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/serverless-apps.html.

Please let us know if you have further question.

@hawflau hawflau added type/question area/debugging blocked/close-if-inactive Blocked for >14 days with no response, will be closed if still inactive after 7 days and removed stage/needs-triage Automatically applied to new issues and PRs, indicating they haven't been looked at. labels Feb 13, 2024
@dangeReis
Copy link

I am running into the same issue not being able to debug using the AWS Toolkit. Is there a supported way to do this? Can someone just test the latest plugin with the latest cli and make sure the hello-world typescript app is debuggable without making any changes (and at least document any changes that need to be made?)

@hawflau
Copy link
Contributor

hawflau commented Apr 1, 2024

It seems to be an open bug in AWS Toolkit - aws/aws-toolkit-vscode#3210

Closing

@hawflau hawflau closed this as completed Apr 1, 2024
Copy link
Contributor

github-actions bot commented Apr 1, 2024

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/debugging blocked/close-if-inactive Blocked for >14 days with no response, will be closed if still inactive after 7 days type/question
Projects
None yet
Development

No branches or pull requests

3 participants