Spring Batch Retry and Skip Logic for Fault-Tolerant Jobs

Q: Spring Batch Retry and Skip Logic for Fault-Tolerant Jobs

Spring Batch provides built-in **retry** and **skip** policies on chunk steps. **Retry** re-attempts processing or writing for a configured exception type up to a limit before failing — appropriate for **transient failures** (deadlock, network blip). **Skip** silently discards items that cause specified exceptions up to a tolerance count — appropriate for **bad records** (parse error, validation). Together with `SkipListener` and `RetryListener` they let you build fault-tolerant pipelines that survive dirty data and infrastructure flaps without aborting the entire batch run.

Intermediate·2 min read·

Goldman SachsFidelityMorgan StanleyCognizantInfosys

Fast recall

Quick revision

Core answer

Spring Batch provides built-in retry and skip policies on chunk steps. Retry re-attempts processing or writing for a configured exception type up to a limit before failing — appropriate for transient failures (deadlock, network blip). Skip silently discards items that cause specified exceptions up to a tolerance count — appropriate for bad records (parse error, validation). Together with SkipListener and RetryListener they let you build fault-tolerant pipelines that survive dirty data and infrastructure flaps without aborting the entire batch run.

Interview-ready guide

Interview answer

Spring Batch's fault tolerance has two complementary policies — skip and retry — and a third concept around when rollback applies.

Skip — discard and continue:

For predictable bad records (parse, validation)
faultTolerant().skip(Exception.class).skipLimit(N)
SkipListener fires for every skipped item — write to a dead-letter destination

Retry — try again:

For transient failures (deadlock, 503)
faultTolerant().retry(Exception.class).retryLimit(N).backOffPolicy(...)
ExponentialBackOffPolicy prevents retry storms
RetryListener emits metrics and observability signals

The single-item recovery cycle:

When a chunk write fails, Spring Batch rolls back the chunk
Then re-reads each item one at a time to isolate the bad row
Good items succeed individually; bad item is skipped (if configured) or fails the step
Processors must be idempotent — they may run twice for the same input

`noRollback` and `processorTransactional(false)`:

noRollback(ValidationException.class) — declares an exception expected and benign
processorTransactional(false) — processor outputs not rolled back
Together they refine the rollback contract

The hard problem — non-transactional side effects:

Emails, API calls, Kafka publishes are NOT undone by rollback
Move them to a separate step that runs after success
Or use the outbox pattern — write a row inside the chunk transaction, dispatch from a separate step

Anti-patterns to call out:

skipLimit(Integer.MAX_VALUE) — silent data corruption
skip(Exception.class) — masks real bugs
Retry without backoff — compounds the failure
Retry on non-idempotent processors — duplicate side effects

In an interview I'd emphasize the single-item recovery cycle and the idempotency requirement — those are what separate practitioners from rote knowledge.

03 · Deep dive