-
Notifications
You must be signed in to change notification settings - Fork 455
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[dbnode] Introduce a field for RPC error code and Resource Exhausted error type #3005
Changes from all commits
9f47d30
d0cadd4
ecdea2b
b92ee9a
bde9a4f
fba214e
ca33832
3f67cf8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -54,6 +54,35 @@ func IsBadRequestError(err error) bool { | |
return false | ||
} | ||
|
||
// IsResourceExhaustedError determines if the error is a resource exhausted error. | ||
func IsResourceExhaustedError(err error) bool { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: Call this |
||
for err != nil { | ||
if e, ok := err.(*rpc.Error); ok && tterrors.IsResourceExhaustedError(e) { //nolint:errorlint | ||
return true | ||
} | ||
if e := xerrors.GetInnerResourceExhaustedError(err); e != nil { | ||
return true | ||
} | ||
err = xerrors.InnerError(err) | ||
} | ||
return false | ||
} | ||
|
||
// WrapIfNonRetryable wraps the error with non-retryable type if appropriate. | ||
func WrapIfNonRetryable(err error) error { | ||
// NB: due to resource exhausted RPC error implementation, it has to be checked | ||
// before bad request error. See NewResourceExhausted() in | ||
// src/dbnode/network/server/tchannelthrift/errors/errors.go for more details. | ||
if IsResourceExhaustedError(err) { | ||
err = xerrors.NewResourceExhaustedError(err) | ||
err = xerrors.NewNonRetryableError(err) | ||
} else if IsBadRequestError(err) { | ||
err = xerrors.NewInvalidParamsError(err) | ||
err = xerrors.NewNonRetryableError(err) | ||
} | ||
return err | ||
} | ||
|
||
// IsConsistencyResultError determines if the error is a consistency result error. | ||
func IsConsistencyResultError(err error) bool { | ||
_, ok := err.(consistencyResultErr) | ||
|
@@ -137,15 +166,15 @@ func newConsistencyResultError( | |
enqueued, responded int, | ||
errs []error, | ||
) consistencyResultError { | ||
// NB(r): if any errors are bad request errors, encapsulate that error | ||
// to ensure the error itself is wholly classified as a bad request error | ||
// NB(r): if any errors are bad request or resource exhausted errors, encapsulate that error | ||
// to ensure the error itself is wholly classified accordingly | ||
var topLevelErr error | ||
for i := 0; i < len(errs); i++ { | ||
if topLevelErr == nil { | ||
topLevelErr = errs[i] | ||
continue | ||
} | ||
if IsBadRequestError(errs[i]) { | ||
if IsBadRequestError(errs[i]) || IsResourceExhaustedError(errs[i]) { | ||
topLevelErr = errs[i] | ||
break | ||
} | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -32,9 +32,15 @@ enum ErrorType { | |
BAD_REQUEST | ||
} | ||
|
||
enum ErrorCode { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: Let's use ErrorFlags instead of ErrorCode as we arrived at during our catchup? Will map the naming of the error value to how we would like to use them |
||
NONE = 0x00, | ||
RESOURCE_EXHAUSTED = 0x01 | ||
} | ||
|
||
exception Error { | ||
1: required ErrorType type = ErrorType.INTERNAL_ERROR | ||
2: required string message | ||
3: optional ErrorCode code = ErrorCode.NONE | ||
} | ||
|
||
exception WriteBatchRawErrors { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are quite a few cases in this PR grouping invalid param with resource exhausted errors does make sense, e.g.:
In such cases I wanted to limit the amount of changes in a single PR and I erred on maintaining externally observable behavior (status codes, published metrics) as it was up until now. This would be fixed in upcoming commits.