knex: Not able to handle when server ends the connection

I’m seeing this problem because there is a connection timeout for 600 seconds from the MySQL server. Then a connection is closed from the server instead of the client.

When Knex then tried to execute a query, the following error comes:

Unhandled rejection Error: BEGIN; - This socket has been ended by the other party
    at Socket.writeAfterFIN [as write] (net.js:297:12)
    at Connection.write (/node_modules/mysql2/lib/connection.js:136:15)
    at Connection.writePacket (/node_modules/mysql2/lib/connection.js:150:10)
    at Query.start (/node_modules/mysql2/lib/commands/query.js:39:14)
    at Query.Command.execute (/node_modules/mysql2/lib/commands/command.js:34:20)
    at Connection.handlePacket (/node_modules/mysql2/lib/connection.js:310:28)
    at Connection.addCommand (/node_modules/mysql2/lib/connection.js:326:10)
    at Connection.query (/node_modules/mysql2/lib/connection.js:397:15)
    at /node_modules/knex/lib/dialects/mysql/index.js:92:18
    at tryCatcher (/node_modules/knex/node_modules/bluebird/js/main/util.js:26:23)
    at Promise._resolveFromResolver (/node_modules/knex/node_modules/bluebird/js/main/promise.js:480:31)
    at new Promise (/node_modules/knex/node_modules/bluebird/js/main/promise.js:70:37)
    at Client._query (/node_modules/knex/lib/dialects/mysql/index.js:88:12)
    at Client.query (/node_modules/knex/lib/client.js:127:24)
    at /node_modules/knex/lib/transaction.js:219:21
    at tryCatcher (/node_modules/knex/node_modules/bluebird/js/main/util.js:26:23)

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 28 (18 by maintainers)

Most upvoted comments

@tmeinders Unless the connection is dropped right after the ping function has verified that the connection is still valid, then what you described should not be a problem. The ping function, as I understand, is not in any way “polling” the database server, but is instead called before a query is run using the connection. This means dead connections should always be discovered before the connection is used to run a query, or as you described it, before the core application tries to use it.

Currently I believe this is the closest to a good solution we have, disregarding the issue of transactions, which quite frankly, one can’t really do anything about to recover the state anyway.

@elhigu @rhys-vdw There’s around 5 issues in this repository that are relevant to this. My proposal is this:

Add default ping method for all dialects as to avoid these issues as much as possible. It’s a part of Pool2 for a reason. (See #922 )
Add a reasonable timeout to transactions rollback; query in case its being called on a dead connection, and if the timeout exceeds, simply ignore the error in order to release the connection to the pool. (Connection broken, and transaction not commited so there’s no harm, and can’t recover the state)

If a user does not want knex to issue a ping query such as SELECT 1 to verify the connection, then they can supply their own ping function in the config following Pool2’s documentation.

Does this sound good to you?

wubzz on Mar 7, 2016