When a fault-tolerant Spring Batch step rolls back a chunk, why does it re-read the chunk item-by-item, and how does that isolate the bad item?

## The problem: bulk mode hides the culprit In steady state a chunk step operates in **bulk mode**: it reads N items, processes all N, and hands the whole list to the `ItemWriter` in one call inside one transaction. That's efficient (one batch INSERT, etc.). But when the write (or a processing step) throws, the transaction rolls back and Batch is left with a list of N items and the knowledge that *one of them* is poison — it has **no idea which**. ## The solution: single-item scanning When the step is `.faultTolerant()` and a rollback happens, Batch does **not** just fail. It has **cached** the items it read for this chunk (fault-tolerant steps buffer read items so they can be replayed without touching the reader again). It then enters a **one-item-at-a-time** processing mode — effectively a chunk size of 1 — and replays the cached items: 1. Take item 1, process it, write it, commit. If it succeeds, move on. 2. Take item 2, process/write/commit. Continue. 3. When it reaches the poison item, it throws again — but now Batch **knows exactly which item** failed because it's the only one in the transaction. 4. Batch applies the configured policy to that one item: `skip(...)` (record it as skipped, roll back just that single-item transaction, continue) or `retry(...)` (attempt it again up to the retry limit). 5. Remaining items after the bad one are likewise processed individually until the chunk is drained, then the step returns to bulk mode for the next chunk. ## Why the reader isn't re-invoked The items were already read and **buffered** by the fault-tolerant infrastructure, so scanning replays from that buffer rather than pulling fresh from the `ItemReader`. This matters because many readers (file cursors, JDBC cursors) can't cheaply re-read. ## Consequences you must know - **Idempotency**: because a rolled-back chunk is re-processed item-by-item, the **`ItemProcessor` (and any side effects it triggers) can run multiple times for the same item**. Processors must be pure/idempotent, or you double-charge, double-email, etc. - **Performance**: a chunk that hits an error degrades from one bulk write to N individual transactions. A high skip rate can tank throughput; that's a signal to fix data upstream or shrink chunk size. - **Retry + rollback interaction**: with `.retry(...)`, the item is retried (each retry can roll back) up to `retryLimit`; if still failing and also skippable, it may then be skipped. - **Skip on read vs process/write**: a skippable exception thrown during **reading** does not need a rollback (nothing was written) — Batch just skips that item and reads the next. Rollback + rescan is specifically the process/write path. ## When it matters in design Choose chunk size knowing that failures are re-scanned: big chunks = great happy-path throughput but expensive failures; small chunks = cheaper failures, more commits. If your writer isn't idempotent, keep chunks small or make the writer upsert-safe.