Hey currently having some issues with my SST local...
# help
n
Hey currently having some issues with my SST local environment. When i launch the local environment I get an internal server error when i hit any endpoint (see second screenshot). I have looked at the cloudwatch logs (1st screenshot) and they don't tell me too much about the actual error itself unfortunately. It seems as well from the local console that I can't see it even logging the req/res as it would normally... I am able to do a deploy either via my command line or seed and the API's work fine so my suspicion is something is up with the local environment, but not sure what. Any assistance would be greatly appreciated 🙏
f
Hey @Noah D It seems the debug stack failed to forward the response to the Lambda function, hence the
Internal Server Error
.
Can you try this to get the log from the websocket server in debug stack: 1. Go to Lambda console; 2. search for the function that starts with
$stage-$app-debug-stack-
, ie
dev-my-app-debug-stack-
3. You should see 3 functions,
Connect
,
Disconnect
, and
Default
4. Copy the function name for the
Default
function 5. Go to CloudWatch console; 6. Search for the log group with the function name from step 4 And if you could pull up the log from the same time and share it here.
n
Hey Frank, Thanks for those tips, will be very helpful in debugging local dev issues in the future 🙌 From what I can see from this it is breaking because I must have accidentally deleted my
debug
dynamo table a bit ago - this was in me trying to fix an issue where one of my tables wasn't deleting properly before i discovered the
setDefaultRemovalPolicy
for non prod environments. I have removed/rebuilt my local dev environment and it has resolved the issue now. However is this something which you think could be addressed further? I.e. either in passing through the error messages better from local development perspective, or potentially resources which the debug stack requires should also be rebuilt if they have been accidentally removed/tampered with?
f
Hey @Noah D, that makes a lot of sense.
Guess what, this exact same issue has been brought up before. I just updated the issue with the solution you suggested https://github.com/serverless-stack/serverless-stack/issues/19
n
Oh awesome, cool to see Frank!