Documentation
¶
Overview ¶
Package retrybp integrates with https://github.com/avast/retry-go that provides some baseplate-specific logic and changes some defaults.
Index ¶
- Constants
- func ContextErrorFilter(err error, next retry.RetryIfFunc) bool
- func Do(ctx context.Context, fn func() error, defaults ...retry.Option) error
- func Filters(filters ...Filter) retry.Option
- func GetOptions(ctx context.Context) (options []retry.Option, ok bool)
- func NetworkErrorFilter(err error, next retry.RetryIfFunc) bool
- func PoolExhaustedFilter(err error, next retry.RetryIfFunc) bool
- func UnrecoverableErrorFilter(err error, next retry.RetryIfFunc) bool
- func WithOptions(ctx context.Context, options ...retry.Option) context.Context
- type Filter
Constants ¶
const ( // DefaultFilterDecision is the default decision returned by Filters at the end // of the filter chain. DefaultFilterDecision = false )
Variables ¶
This section is empty.
Functions ¶
func ContextErrorFilter ¶
func ContextErrorFilter(err error, next retry.RetryIfFunc) bool
ContextErrorFilter returns false if the error is context.Cancelled or context.DeadlineExceeded, otherwise it calls the next filter in the chain.
func Do ¶
Do retries the given function using retry.Do with the default retry.Options provided and overriding them with any options set on the context via WithOptions.
The changes this has compared to retry.Do are:
1. Pulling options from the context. This allows it to be used in middleware where you are not calling Do directly but still want to be able to configure retry behavior per-call.
2. If retry.Do returns a batch of errors (retry.Error), put those in a errorsbp.Batch from baseplate.go.
func Filters ¶
Filters returns a `retry.RetryIf` function that checks the error against the given filters and returns either the decision reached by a filter or the DefaultFilterDecision.
You should not use this with any other retry.RetryIf options as one will override the other.
func GetOptions ¶
GetOptions returns the list of retry.Options set on the context.
func NetworkErrorFilter ¶
func NetworkErrorFilter(err error, next retry.RetryIfFunc) bool
NetworkErrorFilter returns true if the error is a net.Error error otherwise it calls the next filter in the chain.
This filter assumes that the error is due to a problem with the specific connection that was used to make the requset and using a new connection would fix the problem, which is why it retries on every net.Error error rather than inspecting the error for more details to determine if it is appropriate to retry or not.
This should only be used for idempotent requests. You don't want to retry calls that have side effects if the network connection broke down sometime between sending and receiving since you have no way of knowing if the callee receieved and is already processing your request.
func PoolExhaustedFilter ¶
func PoolExhaustedFilter(err error, next retry.RetryIfFunc) bool
PoolExhaustedFilter returns true if the error is an clientpool.ErrExhausted error otherwise it calls the next filter in the chain.
This is safe to use even if a request is not idempotent as this error happens before any network calls are made. It is best paired with some backoff though to give the pool some time to recover.
func UnrecoverableErrorFilter ¶
func UnrecoverableErrorFilter(err error, next retry.RetryIfFunc) bool
UnrecoverableErrorFilter returns false if the error is an retry.Unrecoverable error otherwise it calls the next filter in the chain.
This uses retry.IsRecoverable which relies on wrapping the error with retry.Unrecoverable. It also does not use the "errors" helpers so if the the error returned by retry.Unrecoverable is further wrapped, this will not be able to make a decision.
Types ¶
type Filter ¶
type Filter func(err error, next retry.RetryIfFunc) bool
Filter is a function that is passed an error and attempts to determine if the request should be retried given the error.
Filters should only implement a single check that will generally determine whether the request should be retried or not. If it cannot make that decision on it's own, it should call the next RetryIfFunc in the chain.
If a filter is doing more than that, there's a good chance that it is doing too much.
Source Files