Spring Batch skip and retry policy: distinguish bad input from temporary failure

Classify the failure

Malformed UTF-8 in a manifest is deterministic for those bytes; repetition will not repair it. A brief database deadlock may justify a bounded retry. A missing tenant mapping should stop the job until corrected, not vanish into a skip count. Record the rejected source ID without logging private row text. Upload validation can reject several inputs before the job starts.

Bound the tail

Set retry and skip limits, then fail the job when a threshold is crossed. A COMPLETED job with unexamined skipped financial rows is a misleading outcome. Produce a reconciliation record with accepted, rejected and retried counts. The downloadable Batch fixture now checks one accepted skip, a failed second skip, a transient recovery and exhausted retry. The local SkipListener stores one rejected source key; a real manifest still needs full reconciliation and review.

Boundary sketch

if (malformedReceiptId) rejectManifest();
if (transientDatabaseConflict) retryWithinBound();
if (unknownTenant) stopForOperatorReview();

Cost and verification

Each retry can repeat a chunk's reads and writes. Skips reduce successful output and create reconciliation work; keep both counters bounded. The pseudocode is a policy outline; BatchFaultPolicyContractTest executes the stated skip and retry outcomes.

Common Mistakes

• Do not retry a deterministic parse error.
• Do not skip a row that changes a financial total without reconciliation.
• Do not claim the local Batch tests classify every production database error.

Read next

Spring Batch writers: use a stable source key when a chunk is replayed, Spring MVC multipart receipt import: validate before storing, Spring database backfill: assign historical rows before enforcing ownership, Spring Batch job identity: a manifest ID defines restart versus a new run.

Checked fault-policy paths

Inspect the skip-budget test, retry exhaustion, and the remaining reporting design.