A skip budget counts rejected items across a fault-tolerant step; the next eligible error beyond the limit fails the execution.
Spring Batch skip limits: the next invalid receipt fails the step
Keep the rejected row visible
The checked import reads receipts with IDs 1 through 4. A negative unit count at ID 2 is rejected by the processor. With a skip limit of one, IDs 1, 3 and 4 reach the target table and the step reports one skip. This is a business decision, not a data-cleaning convenience: a money-moving import may require zero skips and an operator review instead. The policy lesson separates deterministic input errors from temporary faults.
Fail on the next bad row
A second run contains bad values at IDs 2 and 3. ID 1 commits, the first invalid row consumes the single skip, and the second invalid row makes the job FAILED. Its target has one row. The failure does not remove an earlier committed chunk. The chunk test shows the same commit boundary without skip configuration.
Reconcile before calling a job complete
A COMPLETED status with one skip is not proof that four expected receipts were accepted. Record the manifest identity, accepted IDs and rejected IDs in a reviewable result. The source kit now persists ID 2 with a reason code in an H2 quarantine table; an operator approval workflow remains unimplemented. See the checked listener.
Checked excerpt
.faultTolerant()
.skip(InvalidReceiptException.class).skipLimit(1)
.retry(TemporaryReceiptException.class).retryLimit(2)Cost and verification
Skipping reduces successful output and may require a second correction run. The step tracks skip counts; storing rejected payloads safely adds disk and privacy costs. The source kit checks the stated local behavior.
Common Mistakes
- Do not describe a completed job with skipped receipts as a full import.
- Do not raise the skip limit to hide an unknown data defect.
- Do not treat a committed earlier chunk as rolled back when a later skip budget fails.
Read next
Spring Batch skip and retry policy: distinguish bad input from temporary failure, Spring Batch retry exhaustion: a temporary error needs a finite stop, Spring Batch chunks: a later failure does not erase an earlier commit, Spring Batch job identity: a manifest ID defines restart versus a new run.
