Detect and handle vici client connection errors #26
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently ClientConn starts a go routine on construction that runs the data read
loop. Errors from this read loop is reported on ClientConn.lastError but as any
request on the client uses ClientConn.readResponse to receive data and that
function will timeout if the underlying connection has issues the
ClientConn.lastError is overwritten with a timeout error. This results in an
invisible and non-recoverable error state of the client.
This change moves the read loop into an exported Listen method that clients are
required to call to start the clients read loop. This bringes clients in control
of the error handling and avoids the subtle bug on error reporting through
ClientConn.lastError.
The main function is updated accordingly to start the client listeners in Go
routines and handle shutdown appropriately.
For better error reporting a String method is added to segmentType so logs will
write the human readable name of the segment instead of the integer based byte
value.