node-mysql2: ECONNRESET

for anyone getting this error randomly. i guess you’re supposed to write this wrapper around pool.query (or whatever call you’re using). stops the problem for me.

function query_with_retries(sql, params, retries_left=1) {
  try {
    return pool.query(sql, params)
  } catch(err) {
    if(retries_left >= 1 && err.code === 'ECONNRESET') {
      console.error({msg:'query_with_retries retrying!', retries_left, err})
      return query_with_retries(sql, params, retries_left-1)
    } else {
      throw err
    }
  }
}

For one I agree that this driver should have a ‘keep alive’ option.  It’s hard to debug and there are no ‘using’ keyword like c# that makes it easy o handle in JavaScript

Thursday, January 10, 2019, 6:42 PM -0500 from notifications@github.com notifications@github.com:

@farzher this is a low level driver and retries out of the scope. It’s not clear from your report if you can catch and process error in your code or it’s something that your code can’t handle ( if latter, it definitely need to be fixed ) The “best practise” usually is to never use individual connections directly and use connection pool ( even if one connection is enough from perf point of view ). But even with pool you absolutely must be able to handle errors from production code and make a decision what to do ( retry / log / report to user ) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .

@sidorares you don’t seem surprised that this causes random errors on production servers. shouldn’t the library do some kind of error catching retries before throwing an error? or is everyone supposed to write custom wrapper code to do that themselves? (i missed the memo) or is computer software just supposed to have some errors?

Very late to the discussion, but @benbotto could you please tell me how you solved this issue finally? I wasn’t able to find any proper solutions on the internet.

I’m sorry to wake the dead here, but I’m struggling to fix this in my code as well. It has caught me by surprise after deploying to production, which isn’t the ideal time to encounter the error.

MySQL has a wait_timeout which is 8 hours by default. If no queries run against a connection in that 8-hour time frame, MySQL evidently terminates the connection. Is my understanding correct in that this library’s connection pool does not handle those terminations and blindly attempts to reuse the terminated connections? Is it not possible for the library to establishing new connections when the server closes idle ones? I see farzher’s code snippet (and thanks for that!), but is there a more keep-alive type solution that can be used as a workaround? I’ve seen some people using a SELECT 1-on-an-interval approach, but I don’t understand how that will keep all of the connections in a pool alive.

I see this in the MySQL documentation, but it doesn’t seem to be the case for mysql2:

With Pool, disconnected connections will be removed from the pool freeing up space for a new connection to be created on the next getConnection call.

Thanks for the support.

this is a low level driver and retries out of the scope

@sidorares that’s fair. maybe make mention that in the readme so lazy people like me are reminded to do proper error handling.

i’m using a pool, you can see the error is at PromisePool.query mysql2/promise.js:323

getting this sometimes randomly. simple test server, nothing complex happening on it.

{ Error: read ECONNRESET
    at PromisePool.query (./node_modules/mysql2/promise.js:323:22)
    at Object.select (./lib/db.js:36:44)
    at <anonymous>
  message: 'read ECONNRESET',
  code: 'ECONNRESET',
  errno: 'ECONNRESET',
  sqlState: undefined,
  sqlMessage: undefined }