Spring Batch job identity: a manifest ID defines restart versus a new run

Keep the manifest stable across recovery

The checked job runs with identifying manifestId MANIFEST-47. Its first execution fails, then a second launch with the same parameter restarts that instance. A different manifest ID creates another instance. Do not add the current time merely to evade a failed job: that creates new work and can duplicate rows already committed. The writer must still make repeated source IDs safe.

Treat completion as a recorded outcome

A separate run with MANIFEST-93 completes four rows. Launching MANIFEST-93 again raises JobInstanceAlreadyCompleteException and leaves the target count at four. That assertion uses one H2 process. The separate JDBC repository fixture now proves one persisted instance across two processes; its digest guard rejects a changed source before restart. The chunk lesson locates the earlier commit.

Checked excerpt

JobParameters run = new JobParametersBuilder()
    .addString("manifestId", "MANIFEST-47")
    .toJobParameters();
JobExecution first = launcher.run(receiptImportJob, run);

Cost and verification

Each execution reads and writes repository metadata. A business manifest key also needs retention and a correction policy for input that has already completed. The isolated source-kit project checks the stated local behavior.

Common Mistakes

• Do not use a random parameter when the intention is to restart the same work.
• Do not equate job completion with proof that every external side effect arrived.
• Do not rely on an in-memory H2 repository for recovery across process loss.

Read next

Spring Batch chunks: a later failure does not erase an earlier commit, Spring Batch writers: use a stable source key when a chunk is replayed, Spring Batch chunk restart: know which receipts committed, Spring tests: separate business rules, wiring and transport.

Related Spring path

Continue with Spring Batch crash recovery: test the repository and input across two processes.