Update how the ECONNRESET error is caught when connection already closing

[kneemer]

Hello 👋 ,

I was having a problem similar to #766 while moving our MySQL database from AWS to Azure. I would get a successful response AND an ECONNRESET error when querying the Azure database.

The fix for #766 didn't seem to be working for me. After digging in a bit, I saw that the error I was getting had a number for the errno property and not the ECONNRESET string:

Error: read ECONNRESET
    at TLSWrap.onStreamRead (internal/stream_base_commons.js:209:20)
    at TLSWrap.callbackTrampoline (internal/async_hooks.js:131:14) {
  errno: -54,
  code: 'ECONNRESET',
  syscall: 'read',
  fatal: true
}

It looks like the errno property changed in node v13

The error.errno property is a negative number which corresponds to the error code defined in libuv Error handling.

Previously, in node v12:

The error.errno property is a number or a string. If it is a number, it is a negative value which corresponds to the error code defined in libuv Error handling. ... In case of a string, it is the same as error.code.

I believe changing err.errno to err.code is backwards compatible given the description in the node v12 docs. It also follows how this error is caught in mysqljs/mysql

If I apply this change locally, our application behaves much better. I attempted to add a test before opening this PR as there didn't seem to be coverage but was not successful. Hopefully the provided documentation and explanation will be enough. 🤞

For additional context, I ran a simple query using our sequelize setup and NODE_DEBUG=net npm run console to see the sequence of events.

[sidorares]

Thanks @kneemer !

I attempted to add a test before opening this PR as there didn't seem to be coverage but was not successful

I can try to guide you. While the change looks straightforward I'd really like to have it covered with unit test. For this scenario we probably need to use fake server in order to trigger ECONNRESET on an underlying tcp connection

( ignore failing coverage check for now, it's a known issue )

[kneemer]

I can try to guide you. While the change looks straightforward I'd really like to have it covered with unit test. For this scenario we probably need to use fake server in order to trigger ECONNRESET on an underlying tcp connection

That makes sense, if you point me to a particular test to emulate I could start there.

[sidorares]

@kneemer https://github.com/sidorares/node-mysql2/blob/3c300a874d8d739338b7ce4954a39cef5a392541/test/integration/connection/test-connect-connection-closed-error.js

[kneemer]

This fails if I revert the err.code back to err.errno. I made the assertion targeted so this doesn't accidentally test some other error condition.

[kneemer]

@sidorares let me know if this test is the right approach or not. If not, any additional guidance would be welcomed. 😄

[sidorares]

All good with the test. I'll try to fix ci today, you might need to rebase or merge master into you branch after

[kpervin]

@sidorares Is there any update on when this might get uploaded to NPM? This package is a dependency of MikroORM and at present is a bit of a breaking issue for environments using Node 13+.

[sidorares]

@kpervin thanks for the ping, somehow this got lost, I'll try to put some attention

[sidorares]

actually this should be published. Can you test with the latest v2.3.3 @kpervin ?

[kpervin]

@sidorares Unfortunately, after looking at the 2.3.3 package in my node_modules, it still seems to be apparent.

I also looked at the 2.3.3 tagged release, and that line seems to be the same.

[daniellockyer]

Ping on this after receiving a report in Ghost.

@sidorares Anything I can do to help? Looks like we need the change releasing 🙂

[kpervin]

Ping on this after receiving a report in Ghost.

Anything I can do to help? Looks like we need the change releasing 🙂

It's already in master, so it only requires a push to NPM.

[ErisDS]

Curious - is there something blocking the release? There seems to be loads of great changes in master but noone is benefiting from them.

This issue in particular is affecting our (Ghost's) users so it would be fab if we could get it onto npm.