retry -package:hspec-contrib

Retry execution of the current memory transaction because it has seen values in TVars which mean that it should not continue (e.g. the TVars represent a shared buffer that is now empty). The implementation may block the thread until one of the TVars that it has read from has been updated. (GHC only)

Retry an operation at most n times (n must be positive). If the operation fails the nth time it will throw that final exception.

retry 1 (print "x")  == print "x"
retry 3 (fail "die") == fail "die"

Retry combinators for monadic actions that may fail This package exposes combinators that can wrap arbitrary monadic actions. They run the action and potentially retry running it with some configurable delay for a configurable number of times. The purpose is to make it easier to work with IO and especially network IO actions that often experience temporary failure and warrant retrying of the original action. For example, a database query may time out for a while, in which case we should hang back for a bit and retry the query instead of simply raising an exception.

retry takes 3 arguments

1. A map m whose keys are exceptions and values are the number of times to retry the action given that the exception occurs.
2. A handler han that decides how to handle an exception when the exception cannot be retried.
3. The stream itself that we want to run this mechanism on.

When evaluating a stream if an exception occurs,

1. The stream evaluation aborts
2. The exception is looked up in m

a. If the exception exists and the mapped value is > 0 then, i. The value is decreased by 1. ii. The stream is resumed from where the exception was called, retrying the action. b. If the exception exists and the mapped value is == 0 then the stream evaluation stops. c. If the exception does not exist then we handle the exception using han. Internal

retry takes 3 arguments

1. A map m whose keys are exceptions and values are the number of times to retry the action given that the exception occurs.
2. A handler han that decides how to handle an exception when the exception cannot be retried.
3. The stream itself that we want to run this mechanism on.

When evaluating a stream if an exception occurs,

1. The stream evaluation aborts
2. The exception is looked up in m

a. If the exception exists and the mapped value is > 0 then, i. The value is decreased by 1. ii. The stream is resumed from where the exception was called, retrying the action. b. If the exception exists and the mapped value is == 0 then the stream evaluation stops. c. If the exception does not exist then we handle the exception using han. Internal

Keep trying a parser until it succeeds. When the parser fails the input consumed till now is dropped and the new instance is tried on the fresh input. Unimplemented

Retry execution of this transaction because it has seen values in TVars that it shouldn't have. This will result in the thread running the transaction being blocked until any TVars referenced in it have been mutated. This is just mzero.

O(1). If the first log leads to failure, continue with the second.

Use given RetrySettings during execution of some client action.

start-stop-daemon --retry argument

Retry on all sync exceptions, async exceptions will still be thrown. The backoff delays between retries grow exponentially plus a random jitter. The backoff for retry attempt number _attempt_ is computed as:

backoffExpBase ** (attempt - 1) + random(0, backoffJitter)

With the default values, the backoff for the first 5 attempts will be:

2 ** 0 + random(0, 1) = 1 + random(0, 1)
2 ** 1 + random(0, 1) = 2 + random(0, 1)
2 ** 2 + random(0, 1) = 4 + random(0, 1)
2 ** 3 + random(0, 1) = 8 + random(0, 1)
2 ** 4 + random(0, 1) = 16 + random(0, 1)

If all retries fail, the last exception is let through.

Retry handler for HTTP requests. Retries a subset of HTTP exceptions and overrides the delay with the Retry-After header if present.

Retry produces a wizard that will retry the entire conversation again if it fails. It is simply retry x = x <|> retry x.

This module exposes combinators that can wrap arbitrary monadic actions. They run the action and potentially retry running it with some configurable delay for a configurable number of times. The express purpose of this library is to make it easier to work with IO and especially network IO actions that often experience temporary failure that warrant retrying of the original action. For example, a database query may time out for a while, in which case we should delay a bit and retry the query.

Unlifted Control.Retry.

forces a retry

The transaction aborted by calling retry, and read the returned TVars. It should be retried when at least one of the TVars has been mutated.

Retry an operation at most n times (n must be positive), while the exception value and type match a predicate. If the operation fails the nth time it will throw that final exception.