Class RecoverAfter


public class RecoverAfter extends ObjectWithJsonToString
Declarative retry/backoff recovery primitive attached to an HttpResponse: "fail the first K matches, then serve the configured success response". This lets a test deterministically exercise a client's retry/backoff logic against a dependency that fails transiently and then recovers.

Counting is 1-based over the expectation's match count (attempt n):

  • Attempts 1..failTimes serve failResponse (or, when none is configured, a default 503 Service Unavailable).
  • Attempt failTimes + 1 and beyond serve the configured success response.
So failTimes = K yields exactly K failures followed by success. When failTimes is null or <= 0 this primitive is inert and the configured response is served unchanged (backward compatible).

Counting is INDEPENDENT of Times: a fail attempt still consumes a match of the expectation but does not consume a Times use beyond what matching already does — the expectation keeps matching across the failure window exactly as it would without this primitive (see HttpActionHandler).

By default the failure counter is per-expectation (off the expectation's match count, so no extra state is held). When idempotencyHeader is set, the counter is instead keyed per (expectationId, header-value) in a node-local RecoveryAttemptRegistry, so each distinct idempotency key gets its own 1..K failure window while requests sharing a key share one window. If idempotencyHeader is configured but the header is ABSENT on a given request, that request falls back to the per-expectation match count.

Relationship to HttpChaosProfile: the chaos profile's succeedFirst/failRequestCount count-window injects probabilistic faults over a window; this primitive is a simpler, deterministic, response-level "fail-then-succeed" with optional idempotency-key scoping, expressed directly on the response action rather than as a chaos field.

Follows the model field/withX/getter convention so it round-trips without a bespoke (de)serializer.