Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Waiting for API to be ready fails intermittently

See original GitHub issue

Describe the bug

Sometimes when starting up swa, it hangs on waiting for the API to be available until it times out and exits. Other times it starts up fine. I’ve been seeing this intermittently for a while and I believe I’ve tracked it down to validateDevServerConfig.

That validation uses two different techniques – for the first check, it just opens a raw TCP socket. If that fails, it falls back to the wait-on library which sends an actual HTTP GET request and validates the response. Since my API function returns a 400 error code for GET / with no parameters, wait-on in the current configuration always fails the check. So I think what is happening is swa succeeds when my API happens to spin up first and only the raw socket check happens, and fails when swa happens to win the race and the wait-on checks happen.

To Reproduce

  • Create an API function that returns 400 error code on a bare GET / request.
  • swa start
  • Depending on if the API starts accepting connections before swa tries to the connect the first time, it’ll either succeed or hang forever waiting until it times out and exits.

Expected behavior swa shouldn’t fail the check if my API function is handling requests but returning an HTTP error response. Ideally also the behavior should be consistent whichever process wins the race.


Screen Shot 2021-08-20 at 9 21 11 PM

Desktop (please complete the following information):

  • OS: MacOS Big Sur 11.5.2 (20G95)
  • Browser [e.g. chrome, safari]: N/A

Issue Analytics

  • State:closed
  • Created 2 years ago
  • Comments:10 (10 by maintainers)

github_iconTop GitHub Comments

codekitchencommented, Aug 23, 2021
manekinekkocommented, Aug 23, 2021

Excellent! Then maybe one of the fixes would that we update the resources property, and use tcp: instead (in addition?) of http:. But this would need some manual testing to make sure we don’t break the current behavior.

   resources: [address(hostname, port), `tcp:${hostname}:${port}`], 

cc @tkamesh @sgollapudi77 @anthonychu

Read more comments on GitHub >

github_iconTop Results From Across the Web

Intermittent API errors when importing EKS clusters ... - GitHub
The issue here does appear to be that trying to import an EKS cluster using the Rancher UI throws an Waiting for API...
Read more >
10 Error Status Codes When Building APIs For The First Time ...
This status code means you haven't yet authenticated against the API. The API doesn't know who you are and it won't serve you....
Read more >
Troubleshooting client response timeouts and errors with API ...
This article helps you troubleshoot intermittent connection errors and related latency issues in Azure API Management.
Read more >
Waiting for containers to start or be ready - Testcontainers
It has to be assumed that the container will stop of its own accord, either with a success or failure exit code. Using...
Read more >
How to Fix Kubernetes 'Node Not Ready' Error - Komodor
Node Not Ready error indicates a machine in a K8s cluster that cannot run pods. Learn about the causes of this problem and...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found