Extend errors with a key -> server mapping context #1
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.
To generate metrics based on observed errors that use the key and/or server, currently users need to do something like parse the message or override the
check_return_code
in order to hook into a place where they can attempt to observe the key used and infer the server involved similar to how the message is generated. This is additionally tricky around theServerIsMarkedDead
errors, since naively callingserver_by_key
would return the incorrect server (handled bydetect_failure
as part of message generation).To ease users ability to track the keys and servers that errors are related to, this extends the base error class and attaches the same context applied to the messages to an attribute
key_map
.As far as I can tell there's no differentiation between server-side and client-side errors, so the
key_map
's semantics are roughly "these were the keys used as part of this operation, and these are the servers we think would have been used with these keys"...a little wishy-washy but likely still useful to the user?