Fixes for Error Handling #231

robblovell · 2021-06-23T17:02:28Z

Errors in error handing appear to have broken the connect/retry logic. I have added some defensive measures that keep the error handling from crashing and now connect is more reliable.

fix #229
mightfix #222

…shchykov#229

…ll be able to await the connectRetry.

formatting

philnash

Thanks for the work on this! I've just left a couple of questions about why you chose to do a couple of things.

philnash · 2021-06-26T06:54:38Z

src/utils.js

-    return false;
-  }
-  const statusCode = err.response.statusCode;
+  const statusCode = err.response ? err.response.statusCode : err.body? err.body.status_code : 0;


What was the situation in which there was no err.response but there was an err.body.status_code? Has that come from the changes you made in NgrokClient?

From what I can tell, this doesn't come from changes to the NgrokClient. This change was made because I was receiving errors in the error handling that should have gone through the retry logic but didn't because of this problem.

Given that one of the unit tests dealing with paid plans is broken now, it looks like this needs further investigation.

The problem occurs when someone has a paid plan and it's in use on another machine. In other words, a tunnel cannot be created because only one tunnel is allowed.

I'd put this in a separate PR personally

philnash · 2021-06-26T06:56:03Z

src/client.js

@@ -13,7 +13,7 @@ class NgrokClient {
  constructor(processUrl) {
    this.internalApi = got.extend({
      prefixUrl: processUrl,
-      retry: 0,
+      retry: 3,


With retries from got and retries based on the isRetriable function we have two different ways that retries might happen. Is there a reason to include retries from got specifically?

Okay, makes sense to put this back to 0.

philnash · 2021-06-26T06:58:03Z

It seems that one of the tests is failing too.

…ign." This reverts commit 72b76f7.

robblovell · 2021-07-01T18:37:08Z

Yes, one test fails, I make a note of that in one of the comments. It think this needs further investigation. 👍

Given that one of the unit tests dealing with paid plans is broken now, it looks like this needs further investigation.

philnash · 2021-07-05T12:47:00Z

Do you reckon you can write a test for when the error handling was failing before, the error from #229? I am not sure what that that situation is, so it would help me understand that this fixes that, but also hopefully help me to fix the failing test under this pull request.

zoetrope69 · 2021-07-16T02:05:35Z

I'm also hitting these errors @robblovell on a paid plan, let me know if you need help debugging together.

philnash · 2021-07-16T02:15:49Z

If someone can provide a way to reproduce the error, I'd be happy to look into what is going on here too. I've just not seen this yet myself.

zoetrope69 · 2021-07-17T13:02:42Z

heres how I was encountering the problem:

main.js

const ngrok = require("ngrok");
// ....
const  ngrokUrl = await ngrok.connect({
  addr: PORT,
  authtoken: NGROK_AUTH_TOKEN,
  region: "eu",
  subdomain: NGROK_SUBDOMAIN,
});

note: i have a paid account

package-json

  "start": "nodemon main.js"

First time running Ngrok does what I expect but then when nodemon refreshes because of a code change in main.js it errors.

philnash · 2021-07-18T03:36:17Z

Thanks for that @zaccolley. I will try to reproduce that myself. I can suggest a workaround though, rather than have ngrok restart when nodemon restarts you can set up your project to start ngrok once and then have nodemon restart just the app and not the tunnel. Even once this is fixed, that is likely a better way to use the two modules together.

zoetrope69 · 2021-07-19T09:23:07Z

... start ngrok once and then have nodemon restart just the app and not the tunnel.

That looks like the best way yeah, maybe it's a bit much to expect this library handle such quick closing of ngrok and recreating

philnash · 2021-07-19T09:29:52Z

My guess right now, until I get some time for this, is that there's something going wrong with closing the process such that when it is started quickly again it is not ready and causes these unexpected errors.

I do think that avoiding stopping and starting the process is likely better anyway though.

zoetrope69 · 2021-07-19T09:32:13Z

I thought the same, ngrok.kill and ngrok.disconnect don't seem to work in this scenario. Which is something I tried, I had it so it would try kill the process, wait and connect again but this didn't work either.

zoetrope69 · 2021-07-19T09:34:18Z

I wonder if it's cause when we do a nodemon refresh we lose track of the current running ngrok process, and ngrok.kill is not going to do anything for that process at that point.

philnash · 2021-07-19T13:09:38Z

My theory is that we need to listen for signals that get sent and kill the ngrok child process there and not during the "exit" event. The Node docs say that you cannot run asynchronous functions for the "exit" event.

By default nodemon sends SIGUSR2, it is probably right to try to close the process for SIGINT (ctrl + c), SIGTERM and SIGHUP (see explanations of Signal codes here) as well as SIGUSR2.

Being able to handle the signals and shutdown gracefully should mean that the processes don't get in a weird way and cause unexpected errors.

Also, stop performing an asynchronous action on process exit. It is not officially supported. However subprocess.kill is not asynchronous, so can be used over the internal killProcess method. Fixes bubenshchykov#239. Should help bubenshchykov#231. Supersedes bubenshchykov#179

philnash · 2021-07-26T09:28:32Z

I think things might be simpler than having to catch all the different signals. On the exit event this module was trying to run asynchronous code, but that's not supported in the exit event. However, killing a process is a synchronous command, so replacing the internal killProcess with just activeProcess.kill() should properly close down the ngrok subprocess and avoid issues when nodemon is restarting the application. This update has been made as #240.

zoetrope69 · 2021-07-26T09:39:15Z

Nice Phil, I think we should still fix the error handling in this PR as there could be another error that isn't caught in the future?

zoetrope69 · 2021-07-26T09:50:18Z

src/client.js

@@ -28,20 +28,12 @@ class NgrokClient {
      }
    } catch (error) {
      let clientError;


Couple of things here:

Now that we're not doing a try ... catch we don't need to create the variable at the start.

I think it is still worth catching errors from JSON.parse should the response body be incorrect JSON

I think the double nested ternary statement makes it hard to follow the logic

We repeat some logic that we can put in a helper function

Could we do something like this:

// .. defined above function getResponse(error) { if (error.response && error.response.body) { let response; try { response = JSON.parse(error.response.body); } catch (e) { throw new NgrokClientError(e.msg, e.details); } return response; } return error; } // ... then const response = getResponse(error); throw new NgrokClientError(error.msg, error.details, response); // ... and } catch (e) { const response = getResponse(e); throw new NgrokClientError(e.msg, e.response, response); }

philnash · 2021-07-26T11:24:36Z

Nice Phil, I think we should still fix the error handling in this PR as there could be another error that isn't caught in the future?

I agree, if there's an issue in the error handling we should indeed fix it. Currently I have a couple of issues with this.

I can't reproduce the error you're talking about, so can't test it myself.
This branch currently fails a test in which an error was being thrown and is now not thrown as expected.

If we can fix the broken test and introduce at least a test case that this new code passes, then I'll be happy to merge.

robblovell and others added 15 commits June 21, 2021 20:52

fixes error: typeerror cannot read property 'body' of undefined buben…

7912a20

…shchykov#229

missing await bubenshchykov#228

b343bb4

this timeout seems to be required for the connect to not hang and sti…

dc3b237

…ll be able to await the connectRetry.

increased timeout until hang can be investigated.

502edd9

okay, duh, return doesn't need await.

ba157db

removed first timeout.

7a07a54

WIP error handling fixes.

1125fdd

spacing

ef53abc

added back retries.

6d82dc8

removed commented out code.

788accd

Update index.js

8709dfa

formatting

formatting to client.js

d44c80e

removed commented out code.

9bc5c7b

formatting

c03e431

formatting

8c9b3e2

philnash reviewed Jun 26, 2021

View reviewed changes

philnash mentioned this pull request Jun 26, 2021

Crashes when calling disconnect function #226

Open

robblovell added 3 commits June 28, 2021 11:24

unnecessary retry logic.

e6eefe5

further protection against rogue errors. Need unit test to align.

72b76f7

Revert "further protection against rogue errors. Need unit test to al…

38799e0

…ign." This reverts commit 72b76f7.

philnash mentioned this pull request Jul 26, 2021

Only listen to process exit event once. #240

Merged

zoetrope69 reviewed Jul 26, 2021

View reviewed changes

enwi mentioned this pull request Oct 18, 2021

4.x fails to start ngrok process #222

Closed

philnash mentioned this pull request Jan 27, 2022

TypeError: Cannot read properties of undefined (reading 'body') #264

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fixes for Error Handling #231

Fixes for Error Handling #231

robblovell commented Jun 23, 2021

philnash left a comment

philnash Jun 26, 2021

robblovell Jun 28, 2021

robblovell Jun 28, 2021

robblovell Jun 28, 2021

zoetrope69 Jul 26, 2021

philnash Jun 26, 2021

robblovell Jun 28, 2021

philnash commented Jun 26, 2021

robblovell commented Jul 1, 2021

philnash commented Jul 5, 2021

zoetrope69 commented Jul 16, 2021

philnash commented Jul 16, 2021

zoetrope69 commented Jul 17, 2021 •

edited

Loading

philnash commented Jul 18, 2021

zoetrope69 commented Jul 19, 2021

philnash commented Jul 19, 2021

zoetrope69 commented Jul 19, 2021

zoetrope69 commented Jul 19, 2021

philnash commented Jul 19, 2021

philnash commented Jul 26, 2021

zoetrope69 commented Jul 26, 2021

zoetrope69 Jul 26, 2021 •

edited

Loading

philnash commented Jul 26, 2021

Fixes for Error Handling #231

Are you sure you want to change the base?

Fixes for Error Handling #231

Conversation

robblovell commented Jun 23, 2021

philnash left a comment

Choose a reason for hiding this comment

philnash Jun 26, 2021

Choose a reason for hiding this comment

robblovell Jun 28, 2021

Choose a reason for hiding this comment

robblovell Jun 28, 2021

Choose a reason for hiding this comment

robblovell Jun 28, 2021

Choose a reason for hiding this comment

zoetrope69 Jul 26, 2021

Choose a reason for hiding this comment

philnash Jun 26, 2021

Choose a reason for hiding this comment

robblovell Jun 28, 2021

Choose a reason for hiding this comment

philnash commented Jun 26, 2021

robblovell commented Jul 1, 2021

philnash commented Jul 5, 2021

zoetrope69 commented Jul 16, 2021

philnash commented Jul 16, 2021

zoetrope69 commented Jul 17, 2021 • edited Loading

philnash commented Jul 18, 2021

zoetrope69 commented Jul 19, 2021

philnash commented Jul 19, 2021

zoetrope69 commented Jul 19, 2021

zoetrope69 commented Jul 19, 2021

philnash commented Jul 19, 2021

philnash commented Jul 26, 2021

zoetrope69 commented Jul 26, 2021

zoetrope69 Jul 26, 2021 • edited Loading

Choose a reason for hiding this comment

philnash commented Jul 26, 2021

zoetrope69 commented Jul 17, 2021 •

edited

Loading

zoetrope69 Jul 26, 2021 •

edited

Loading