https://serverless-stack.com/ logo
Join Slack
Powered by
I’m having issues with the debugger in vscode afte...
# help
p
I’m having issues with the debugger in vscode after transitioning to a monorepo style structure using yarn workspaces. I have the src for my lambdas in 
/packages/backend/src/services
and I’m launching 
sst start
using the vscode launch script. That works fine. I can see in the logs that the requests are coming through and the handlers are being called, but my breakpoints in VSCode are never hit. Additionally, every time they are called, esbuild seemingly is compiling the handlers before responding (It shows so in the terminal). I don’t believe it was doing that previously. I’m wondering if it has something to do with the new file organization structure and if I need to modify an sst config somewhere. I’ve seen the yarn monorepo example and nothing stood out to me. Any advice would be welcome!
Terminal Output:
Copy code
Debugger attached.
Waiting for the debugger to disconnect...
Waiting for the debugger to disconnect...
2021-10-26T18:10:19.220Z        undefined       INFO    Executing '.build/src/services/main.handler' in function directory '<obfuscated>/packages/backend'
- /<obfuscated>/.npm/_npx/83619/lib/node_modules/aws-lambda-ric/bin/index.jslient/index.jslient.jsuntime-client.node'
2021-10-26T18:10:19.288Z        undefined       INFO    Executing '.build/src/services/main.handler' in function directory '<obfuscated>/packages/backend'
- /<obfuscated>/.npm/_npx/83613/lib/node_modules/aws-lambda-ric/bin/index.jslient/index.jslient.jsuntime-client.node'
Example of it compiling when attaching:
The requests are actually timing out as well.
The stack works when deployed as well.
@Frank would love some help on this if you have a moment - my sst debug is basically broken now and I’m not sure if I need to revert everything because sst doesn’t support a workspaces model or something else silly that I just missed.
Ended up moving all the SST stuff back to the root and that resolved the issues
It’s weird that it was finding the source files, but it was not responding nor picking up breakpoints
f
Hey @Patrick Gold, sorry about the delayed response.
Hmm.. the terminal output you shared above looks really weird.
p
Yeah it was really weird. I could try replicating with a sample repo
f
Yeah, that’d be really helpful!
Let me also pull in @thdxr and see if he can spot anything obvious.
t
I'm not sure - I'm planning on setting up vscode tomorrow to learn more about the debugger
p
This happened with sst start as well FWIW
t
even without the debugger?
p
Hmm I believe so yeah. Hard to say for sure since the issue is resolved now
f
Just to clarify:
the requests are coming through and the handlers are being called
Did you see something like this in ur terminal when a request came in?
Copy code
42cb9618-828c-42d3-94f5-45f91ed9c771 REQUEST name-of-the-lambda [src/lambda.main] invoked
And did the function ran fine afterwards, ie. printed out the response
Copy code
42cb9618-828c-42d3-94f5-45f91ed9c771 RESPONSE {"statusCode":200,"body":"hi"}
esbuild seemingly is compiling the handlers before responding (It shows so in the terminal)
Was the compiling output shown before the 
REQUEST
line?
Yeah, if you get a chance to reproduce this with a sample repo, definitely share it our way. We can give it a go.
p
Yes, the invoked output was there
No, the functions were not running. It would kick off a build of the function which is what my screenshot shows then just timeout
I'm not sure on order of the lines
Will try to reproduce
f
Thanks @Patrick Gold!
Open in Slack
PreviousNext
Powered by