It appears manually deleting the `stack` and `debu...
# help
d
It appears manually deleting the
stack
and
debug stack
causes
yarn start
to fail with
Copy code
WebSocket connection error Error: getaddrinfo ENOTFOUND <http://NOTTELLING.execute-api.us-east-1.amazonaws.com|NOTTELLING.execute-api.us-east-1.amazonaws.com>
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:67:26) {
  errno: -3008,
  code: 'ENOTFOUND',
  syscall: 'getaddrinfo',
  hostname: '<http://NOTTELLING.execute-api.us-east-1.amazonaws.com|NOTTELLING.execute-api.us-east-1.amazonaws.com>'
}
Feels like this should instead either: • CLI Error out with debug stack not found • CLI detect debug stack missing and redeploy it In the mean time… is there a SST command to redeploy the debug stack?
t
This shouldn't happen, I routinely do this
hm
Are you just stuck now? Can you try sst start after deleting
.build
folder?
d
yup… deleting
.build
folder worked… its redeploying debug stack now. Seems like a Bug?
t
yeah that's odd, not familiar with how the debug stack gets deployed but let me make an issue
f
Oh yeah,
sst start
tries to cache infrastructure state to speed up subsequent
sst start
time. We are going to remove the local cache and check against the real template last deployed to CFN.
s
I’m not sure if that was fixed already but I’m on 0.47.0 and get into a infinite loop of websocket errors:
WebSocket connection error Error: getaddrinfo ENOTFOUND 8gde36p08k.execute-api.me-south-1.amazonaws.com at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js6726) { errno: -3008, code: ‘ENOTFOUND’, syscall: ‘getaddrinfo’, hostname: ‘8gde36p08k.execute-api.me-south-1.amazonaws.com’ }
In my case deletion of .build fixed the issue. I think the reason why it stop working was that during initial deployment of the stack I get a port allocation error.
I killed the process and executed ‘yarn start’ again but it didn’t work.
OS restart didn’t help, only deletion of .build folder fixed the problem. I think that killing node process from shell resulted in hanging process that later caused this whole issue on next ‘yarn start’
f
Hey @Slawomir Stec, sorry for the late follow up. This issue might be fixed in v0.50.0. Let me know if you still get this issue after updating!
s
I’m using 0.50.0 and no issue so far, thank you!