https://serverless-stack.com/ logo
Join Slack
Powered by
I’m getting frequent 504 errors when locally debug...
# sst
d
I’m getting frequent 504 errors when locally debugging. These errors are occurring in my mobile app after requests to my local debug session fail. In fact, when I get these errors, my local debug stack never even receives the request. Have I misconfigured something (again)? 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "<http://www.w3.org/TR/html4/loose.dtd>">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>504 ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
CloudFront attempted to establish a connection with the origin, but either the attempt failed or the origin closed the connection.
We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
<BR clear="all">
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: ZsfXobFJPMJp_60zGS55R6cbfKCgGXEzGjauVaIWFFVxC_ZZHZiB0g==
</PRE>
<ADDRESS>
</ADDRESS>
</BODY></HTML>
i’d say this is happening to about 20% of my requests. it persists through starts & stops of the local debug session. and it’s a new issue, it wasn’t happening a while back.
t
what are these requests to?
d
appsync
t
odd I wonder why the error is coming from cloudfront?
d
ok let me grab a full request and drop it in here so you can see
oh i think i see the issue……these requests aren’t resolving within 30 seconds
i am experiencing a lot of latency with local debugging
f
Do you mean these 20% of requests (ie. that result in 504 error), they do reach ur local, but take longer than 30sec to run on ur local?
Hey David, just following up here. The issue sounds super weird. I wanted to make sure it’s resolved for you.
d
hey @Frank. i wanted to reply when i had a way to reliably replicate the issue so i’m not wasting your time. however, it’s sporadic and i can’t replicate it reliably. i’m thinking the issue is that VSCode gets choked with rebuilds of my project and doesn’t have the CPU to handle the incoming requests. I have a brand new fully maxed out macbook pro so my machine is quite powerful. i originally posted here to see if i’m the only one having this issue, and nobody else chimed in so perhaps i am. in general i’m having some reliability issues with local debugging. performance is slow, breakpoints aren’t always stopped on and the requests sometimes fail. i don’t think i’m doing anything particularly interesting with SST. i do run a monorepo setup. previously, SST was a leaf node of the monorepo, but to upgrade past 0.48, i had to move SST to the root and honestly that’s when this behavior started. i suggest we should close this topic though. these are vague reports and i don’t have a step-by-step way to replicate an issue. if i’m able to identify a specific issue with a way to replicate it, i’ll let you know at that time. thanks for the follow-up.
j
@David Martin what version of SST are you on right now? I know we did a bunch of work recently to make it perform better for larger projects.
d
SST: 0.61.0 CDK: 2.7.0
j
Hmm that should have those fixes. @Frank any idea what’s going on here?
f
Yeah, there have been a number of reports of debugging SST in VS Code being unreliable, and ppl have suggested that it might be CPU/Memory related.
Ppl also mentioned that this problem is not there after switching to Webstorm. So it sounds like a VS Code specific issue.
Let’s close this discussion. I will reproduce this issue on my end, and make sure the live debugging experience is smooth on VS Code.
j
Seems sourcemap related also?
f
hmm.. @David Martin do you know if u have source map enabled?
d
no, i don’t enable source maps. just so we’re 100% on the same page, i’m assuming this is what you’re referring to: https://docs.serverless-stack.com/advanced/source-maps
today, things are working fine with VSCode. breakpoints are hit, responses succeed. when asked if i was the only one having this issue, it wasn’t working well. 🤷‍♂️ i still love SST though. wouldn’t trade it.
also i’ll give webstorm a try if this happens again
j
Yeah we’d like to figure out why it’s struggling on VS Code though.
d
next time it happens, i’ll leave it running and reply here. we can screenshare if it helps diagnose it.
j
Great! Thanks @David Martin.
d
If you guys want to screenshare, I’m able to reliable reproduce the conditions that cause debugging to eat up the CPU. Just lmk.
j
@Frank @thdxr let's look into this?
f
Hey @David Martin I can Zoom anytime in the next couple of hours if you are around.
d
Sorry guys I have a class tonight. I'll ping you tomorrow when the cpu is spinning.
f
Yup! DM me 😁
d
@Frank @thdxr quick follow up from our zoom: i set the srcPath for the project. was easy, everything continues to work. however, this did not resolve the high CPU problem with VSCode that leads to the dropped requests & inability to debug. i’ve been running yarn sst start from the command line, not within VSCode. this totally resolves the high CPU issue. everything works perfectly outside of VSCode. this works for now. i’d like to have debugging work again. i might try webstorm later this week. or try to link the chrome debugger.
t
ah ok thanks for the update! we need to spend a deep dive into vscode debugging and see what we can do
d
yeah i think that’ll help out folks. if you want, i can assist somehow since my config does recreate the problem.
Open in Slack
PreviousNext
Powered by