Remove shard session held in vtgate for reserved connection on connection failure

[harshit-gangal]

When a reserved connection is used in transaction it is natural to call rollback/commit when a query execution failed.
But, when a reserved connection is used in non-transaction/autocommit mode, VTGate needs to handle to case to release the held reserved connection in session, to move forward on next query and recreate the reserved connection with correct settings.

[sougou]

I think it's ok to keep the connection. Otherwise, we'll start churning connections on things like syntax error, etc. Was there a use case where keeping the connection would be harmful?

[harshit-gangal]

I think it's ok to keep the connection. Otherwise, we'll start churning connections on things like syntax error, etc. Was there a use case where keeping the connection would be harmful?

In a transaction, when a connection is closed/lost, server expectation is to receive commit/rollback.
In case of reserved connection and not in a transaction, a connection when closed/lost needs to be renewed on getting error from tabletserver otherwise the client will keep sending the query to errored reserved connection.

Currently, the reset happens only for below two mysql error codes.

sqlErr := mysql.NewSQLErrorFromError(err).(*mysql.SQLError)
if sqlErr.Number() == mysql.CRServerGone || sqlErr.Number() == mysql.CRServerLost {
   session.ResetShard(info.alias)
}

[harshit-gangal]

// CRServerGone is CR_SERVER_GONE_ERROR.
// This is returned if the client tries to send a command but it fails.
CRServerGone = 2006

// CRServerLost is CR_SERVER_LOST.
// Used when:
// - the client cannot write an initial auth packet.
// - the client cannot read an initial auth packet.
// - the client cannot read a response from the server.
CRServerLost = 2013

We should also look at the list of what other possible error codes which says that the server connection is no longer valid.