Unable to debug lambda code on first request because RIC waits to load handler

Open
#75 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
aws, node.js, typescript
Domain
cloud, devtools

Research direction

Start from the aws-lambda-ric index.handler entry point and trace when the runtime domain and Node.js process are started relative to the first request. Compare that startup path with the documented --inspect and --inspect-brk behavior. Done means the debugger can start after RIE/RIC launches and attach before the first request reaches the breakpoint.

Written by the indexing model from the issue text.

Description

I use the following command to run Runtime Interface Emulator/Runtime Interface Client:
/usr/local/bin/aws-lambda-rie /usr/bin/npx --node-options="--inspect-brk=0.0.0.0:9229" aws-lambda-ric index.handler

I use VS Code to debug my containerized lambda.

Because of the way the RIE or RIC is instrumented, it doesn't load the node process until the first request is initiated.
Because of this the node debugger process doesn't get launched until after the first request. To get around this, I have to issue the request, it hangs because the debugger is waiting for me to attach to it and give it action, then I attach to it, and only then does the debugger start, otherwise the request just sits.

Note: If I use --inspect instead of --inspect-brk then I have to issue two requests. The first request is when the debugger starts. Once the file is loaded, then I attach to the debugger. Now on the second request I can get proper debugging.

Neither solution is adequate. Ideally, I would

  1. Start the RIE/RIC
  2. RIE/RIC would start the node process. This would allow the debugger process to start and the dev could attach to it.
  3. I'd issue my request and it'd stop exactly at the breakpoint where I needed it to be.

Here is my launch.json file

{
    "configurations": [
        {
            "address": "0.0.0.0",
            "localRoot": "${workspaceFolder}",
            "name": "Attach to Lambda's Node Debugger Process",
            "port": 9229,
            "remoteRoot": "/var/task",
            "request": "attach",
            "skipFiles": [
                "<node_internals>/**"
            ],
            "type": "node",
            "continueOnAttach": true
        },
    ]
}

When I start the program here's what happens:

[INFO] (rapid) exec '/usr/bin/npx' (cwd=/var/task, handler=index.handler)

Then I issue an request. Here's what happens:

[INFO] (rapid) Configuring and starting Operator Domain
[INFO] (rapid) Starting runtime domain
START RequestId: d6fe2e68-87d3-4918-bf02-e96665ad7dfa Version: $LATEST
Debugger listening on ws://0.0.0.0:9229/00b2748e-8cc0-492e-8ecf-5d8517802ef7
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.   

The program stops here because I've initialized it with the --inspect-brk flag so that I don't need to the request twice. (This is where the inefficiency occurs: The process which starts the runtime domain should get initialized earlier and allow the debugger process to get started.)

I then attach to the debugger port and am able to get to my line of code.

Dominant language
TypeScript
Stars
224
Forks
60
Avg merge
26m
Merged PRs (30d)
2

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from aws/aws-lambda-nodejs-runtime-interface-client

All issues in aws/aws-lambda-nodejs-runtime-interface-client

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.