Stopping a job during a non-interruptible Tasklet step leaves the job in inconsistent state

spring-batch:4.1.2.RELEASE

We have a job with multiple steps, the first being a MethodInvokingTaskletAdapter step that does some initial setup for the job in a single transaction. If this method fails, the transaction rolls back and that step will run again.

However, if the job is cancelled via jobOperator.stop(...), the initializeStep continues to run (as expected) to completion and its results are still committed (since no exception is thrown). However, the state of that step is listed as STOPPED.

If the job is restarted, spring batch runs that step again, even though that step has essentially completed successfully and committed its results.

This would seem to violate the restart contract. Since the tasklet in this case does not implement the StoppableTasklet interface, there is no way for spring batch to inform the step to stop. If the tasklet doesn't error, shouldn't the assumption be that the step is COMPLETE?

If the currently running tasklet implements StoppableTasklet and throws a JobInterruptedException, only then should it be marked as STOPPED (and the transaction rolled back).

This behavior seems to work fine for ChunkOrientedTasklets, as they have the granularity to check for interruption and throw the JobInterruptedException (essentially as if the were a StoppableTasklet in my case).

Start by tracing jobOperator.stop(...) through the MethodInvokingTaskletAdapter step and compare its behavior with StoppableTasklet and ChunkOrientedTasklets. Verify the restart behavior for a tasklet that completes after a stop request, and add coverage showing that the step status and restart outcome match the intended interruption contract.