Spring outbox retries: due time, delay cap, and attempt accounting

Schedule after a failed attempt

The local model starts with zero failures and due time zero. A failed claimed attempt increments failures, clears its claim, and sets next_attempt_at to the logical failure time plus 10 units. The second failure waits 20 units. A third would wait no more than 40. The test proves that a claim one unit before each due time fails and a claim at the due time succeeds.

This is a bounded deterministic policy, not a recommendation to use 10 milliseconds or seconds in production. The fixture uses abstract time units. A real worker needs a retry classification, randomized jitter for shared outages, an elapsed-time budget, and metrics for age and attempt count. The dead state handles exhausted work.

Retries can repeat success

A network timeout does not prove that the consumer rejected the request. The consumer may have committed and lost its response. Retrying the same stable event ID is safer than generating a replacement ID, provided the consumer ledger and business mutation commit together. Do not hold the producer transaction open while waiting for a retry.

The test calls fail directly. It does not classify HTTP status, broker acknowledgement, connection reset, or permanent schema rejection. Those belong to the actual transport adapter and have separate operational costs.

Checked source

update delivery_outbox set failures = failures + 1,
    next_attempt_at = ? + case when failures = 0 then 10
        when failures = 1 then 20 else 40 end
where event_id = ? and claim_token = ?;

Verification boundary

OutboxRelayFlowTest has seven local tests in the downloadable Spring source kit. The excerpt is shortened; the kit contains the complete test.

Costs and limits

The schedule is checked with one event and a logical clock. No timer, queue, jitter, outage storm, or real latency distribution is measured.

Common Mistakes

• Do not retry immediately in a tight loop.
• Do not issue a new event ID for the same delivery attempt.
• Do not call every failure transient.

Read next

Spring outbox relay: claim, deliver, and acknowledge one event, Spring outbox retry budget: park a poison event for inspection, Spring consumer idempotency: reserve an event ID with the stock mutation, Spring outbox claims: lease expiry and token-fenced acknowledgement.

Continue with scheduled relay checks

Continue with Spring scheduled retries: leave failed work pending until its due time.