Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

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

未關閉
  • 哪裡不對？
#75 2 則留言 1 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
35/100
Issue 類型
功能
描述清晰度
基本清楚
活躍度
停滯
技術堆疊
aws, node.js, typescript
領域
cloud, devtools

研究方向

從 aws-lambda-ric index.handler 進入點開始，追蹤 runtime domain 和 Node.js 程序相對於第一個請求何時啟動。將該啟動路徑與文件中所述的 --inspect 和 --inspect-brk 行為進行比較。當偵錯器能在 RIE/RIC 啟動後啟動並連線，且在第一個請求到達 breakpoint 之前完成連線時，即視為完成。

由索引模型根據 Issue 內容生成。

描述

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.

主要語言
TypeScript
星號
224
分支
60
平均合併
26 分鐘
30 天內合併 PR
2

環境準備

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

aws/aws-lambda-nodejs-runtime-interface-client 的其他 Issue

查看 aws/aws-lambda-nodejs-runtime-interface-client 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。