A RetryPolicyM is a function that takes an RetryStatus and possibly returns a delay in microseconds. Iteration numbers start at zero and increase by one on each retry. A *Nothing* return value from the function implies we have reached the retry limit.

Please note that RetryPolicyM is a Monoid. You can collapse multiple strategies into one using mappend or <>. The semantics of this combination are as follows:

1. If either policy returns Nothing, the combined policy returns Nothing. This can be used to inhibit after a number of retries, for example.
2. If both policies return a delay, the larger delay will be used. This is quite natural when combining multiple policies to achieve a certain effect.

Example:

One can easily define an exponential backoff policy with a limited number of retries:

> limitedBackoff = exponentialBackoff 50 <> limitRetries 5

Naturally, mempty will retry immediately (delay 0) for an unlimited number of retries, forming the identity for the Monoid.

The default under def implements a constant 50ms delay, up to 5 times:

> def = constantDelay 50000 <> limitRetries 5

For anything more complex, just define your own RetryPolicyM:

> myPolicy = retryPolicy $ \ rs -> if rsIterNumber n > 10 then Just 1000 else Just 10000

Since 0.7.

Simplified RetryPolicyM without any use of the monadic context in determining policy. Mostly maintains backwards compatitibility with type signatures pre-0.7.

Helper for making simplified policies that don't use the monadic context.

Datatype with stats about retries made thus far. The constructor is deliberately not exported to make additional fields easier to add in a backward-compatible manner. To read or modify fields in RetryStatus, use the accessors or lenses below. Note that if you don't want to use lenses, the exported field names can be used for updates:

> retryStatus { rsIterNumber = newIterNumber }
> retryStatus & rsIterNumberL .~ newIterNumber

Iteration number, where 0 is the first try

Delay incurred so far from retries in microseconds

Previous attempt's delay. Will always be Nothing on first run.

Initial, default retry status. Exported mostly to allow user code to test their handlers and retry policies. Use fields or lenses to update.

Retry combinator for actions that don't raise exceptions, but signal in their type the outcome has failed. Examples are the Maybe, Either and EitherT monads.

Let's write a function that always fails and watch this combinator retry it 5 additional times following the initial run:

>>> import Data.Maybe
>>> let f _ = putStrLn "Running action" >> return Nothing
>>> retrying def (const $ return . isNothing) f
Running action
Running action
Running action
Running action
Running action
Running action
Nothing

Note how the latest failing result is returned after all retries have been exhausted.

Run an action and recover from a raised exception by potentially retrying the action a number of times. Note that if you're going to use a handler for SomeException, you should add explicit cases *earlier* in the list of handlers to reject AsyncException and SomeAsyncException, as catching these can cause thread and program hangs. recoverAll already does this for you so if you just plan on catching SomeException, you may as well ues recoverAll

Retry ALL exceptions that may be raised. To be used with caution; this matches the exception on SomeException. Note that this handler explicitly does not handle AsyncException nor SomeAsyncException (for versions of base >= 4.7). It is not a good idea to catch async exceptions as it can result in hanging threads and programs. Note that if you just throw an exception to this thread that does not descend from SomeException, recoverAll will catch it.

See how the action below is run once and retried 5 more times before finally failing for good:

>>> let f _ = putStrLn "Running action" >> error "this is an error"
>>> recoverAll def f
Running action
Running action
Running action
Running action
Running action
Running action
*** Exception: this is an error

Helper function for constructing handler functions of the form required by recovering.

Implement a constant delay with unlimited retries.

Grow delay exponentially each iteration. Each delay will increase by a factor of two.

FullJitter exponential backoff as explained in AWS Architecture Blog article.

http://www.awsarchitectureblog.com/2015/03/backoff.html

temp = min(cap, base * 2 ** attempt)

sleep = temp 2 + random_between(0, temp 2)

Implement Fibonacci backoff.

Retry immediately, but only up to n times.

Add an upperbound to a policy such that once the given time-delay amount has been reached or exceeded, the policy will stop retrying and fail.

Set a time-upperbound for any delays that may be directed by the given policy. This function does not terminate the retrying. The policy `capDelay maxDelay (exponentialBackoff n)` will never stop retrying. It will reach a state where it retries forever with a delay of maxDelay between each one. To get termination you need to use one of the limitRetries function variants.

Run given policy up to N iterations and gather results. In the pair, the Int is the iteration number and the Maybe Int is the delay in microseconds.

Run given policy up to N iterations and pretty print results on the console.