You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add a new configuration option to the retry middleware that would make it possible to customize which types of errors are retryable.
Example use case
At the company I work for, we use a custom error package that allows to specify error severities. We have a convention that "retryable errors" are propagated as "Runtime Severity".
It would be great if I could just reuse the existing Retry middleware and have it run a custom function to
check if the returned errors is retryable or not.
A more concrete use case would be to not retry if the input message is in an invalid format, because even if we retry, the result will always be the same once the msg payload is corrupted somehow.
How it can look like in code
// Default implementationfuncallErrorsAreRetryable(errerror) bool {
returntrue
}
// Retry provides a middleware that retries the handler if errors are returned.// The retry behaviour is configurable, with exponential backoff and maximum elapsed time.typeRetrystruct {
// existing options ...// RetryableError returns true whenever an error can be retried// by default all errors are retryable.RetryableErrorfunc(error) bool
}
// Middleware returns the Retry middleware.func (rRetry) Middleware(h message.HandlerFunc) message.HandlerFunc {
returnfunc(msg*message.Message) ([]*message.Message, error) {
producedMessages, err:=h(msg)
iferr==nil {
returnproducedMessages, nil
}
// >>> Custom implementation to check if the error is retryable or notifok:=r.RetryableError(err); !ok {
// If the error is not retryable we completely skip the middleware implementation and return// whatever the inner handler function returnsreturnproducedMessages, err
}
expBackoff:=backoff.NewExponentialBackOff()
expBackoff.InitialInterval=r.InitialInterval// existing implementation ...
}
I would be willing to implement this!
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
Feature request
Description
Add a new configuration option to the retry middleware that would make it possible to customize which types of errors are retryable.
Example use case
At the company I work for, we use a custom error package that allows to specify error severities. We have a convention that "retryable errors" are propagated as "Runtime Severity".
It would be great if I could just reuse the existing Retry middleware and have it run a custom function to
check if the returned errors is retryable or not.
A more concrete use case would be to not retry if the input message is in an invalid format, because even if we retry, the result will always be the same once the msg payload is corrupted somehow.
How it can look like in code
I would be willing to implement this!
The text was updated successfully, but these errors were encountered: