-
Notifications
You must be signed in to change notification settings - Fork 315
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error catch causes error that hides the real error. #229
Comments
Perhaps there are changes in the replies from the NGROK api that are causing problems? Not sure. But it looks like there are some gremlins in here somewhere that cause the error handling to crash and the retry logic to fail. Periodically, ECONNREFUSED 127.0.0.1:4040 is returned. |
I'm facing the same issue. I can reproduce it by updating my Ngrok token to a wrong one, and then I get the |
If the HTTP client catches an error but it doesn't have a response, then it is not an HTTP error, so we'll throw the original error instead. This will surface what is causing an error that isn't because of an HTTP response in the client. Should fix #229, or at least help diagnose it.
If the HTTP client catches an error but it doesn't have a response, then it is not an HTTP error, so we'll throw the original error instead. This will surface what is causing an error that isn't because of an HTTP response in the client. Should fix #229, or at least help diagnose it.
Also, there is a problem in the client code:
Here:
Some errors don't have a response or a response.body and you "typeerror cannot read property 'body' of undefined", probably from the second catch... It would be better to just return the error. When doing so, you get a much more useful message that helped to debug the above missing await (ngrok is not yet ready to start tunnels):
in client.js
The text was updated successfully, but these errors were encountered: