retrybp

package
v0.7.1 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Dec 8, 2020 License: BSD-3-Clause Imports: 9 Imported by: 0

Documentation

Overview

Package retrybp integrates with https://github.com/avast/retry-go that provides some baseplate-specific logic and changes some defaults.

Index

Constants

View Source
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 CappedExponentialBackoff added in v0.7.0

func CappedExponentialBackoff(args CappedExponentialBackoffArgs) retry.Option

CappedExponentialBackoff is an exponentially backoff delay implementation that makes sure the delays are properly capped.

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

func Do(ctx context.Context, fn func() error, defaults ...retry.Option) error

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

func Filters(filters ...Filter) retry.Option

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 FixedDelay added in v0.7.0

func FixedDelay(delay time.Duration) retry.Option

FixedDelay is a delay option to use fixed delay between retries.

To achieve the same result via upstream retry package's API, you would need to combine retry.Delay and retry.DelayType(retry.FixedDelay), which is confusing and error-prone. As a result we provide this API to make things easier.

If you want to combine FixedDelay with a random jitter, you could use FixedDelayFunc with retry.RandomDelay, example:

retry.DelayType(retry.CombineDelay(retry.RandomDelay, retrybp.FixedDelayFunc(delay)))

func FixedDelayFunc added in v0.7.0

func FixedDelayFunc(delay time.Duration) retry.DelayTypeFunc

FixedDelayFunc is an retry.DelayTypeFunc implementation causing fixed delays.

func GetOptions

func GetOptions(ctx context.Context) (options []retry.Option, ok bool)

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.

func WithOptions

func WithOptions(ctx context.Context, options ...retry.Option) context.Context

WithOptions sets the given retry.Options on the given context.

Types

type CappedExponentialBackoffArgs added in v0.7.0

type CappedExponentialBackoffArgs struct {
	// The initial delay.
	// If <=0, retry.DefaultDelay will be used.
	// If retry.DefaultDelay <= 0, 1 nanosecond will be used.
	InitialDelay time.Duration

	// The cap of InitialDelay<<n. If <=0, it will only be capped at MaxExponent.
	//
	// Please note that it doesn't cap the MaxJitter part,
	// so the actual max delay could be MaxDelay+MaxJitter.
	MaxDelay time.Duration

	// We calculate the delay before jitter by using InitialDelay<<n
	// (n being the number of retries). MaxExponent caps the n part.
	//
	// If <=0, it will be calculated based on InitialDelay to make sure that it
	// won't overflow signed int64.
	// If it's set to a value too high that would overflow,
	// it will also be adjusted automatically.
	//
	// Please note that MaxExponent doesn't limit the number of actual retries.
	// It only caps the number of retries used in delay value calculation.
	MaxExponent int

	// Max random jitter to be added to each retry delay.
	// If <=0, no random jitter will be added.
	MaxJitter time.Duration
}

CappedExponentialBackoffArgs defines the args used in CappedExponentialBackoff retry option.

All args are optional.

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.

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL