Step lifecycle listener for when step is completed

[cezarykluczynski]

I'm looking for a way to execute a callback when step is completed. StepExecutionListener does not work, because in afterStep, step is not acutally completed yet, because it's exit status can still be changed, and status in the DB table is not COMPLETED, but STARTED.

I'm looking for a way to do it, because after every step, I want to fire an automatic backup of a completed step. For that, it is required that all steps are completed, because if state is later recreated from this backup, Spring Batch would not process further.

I haven't found any way to do it in a clean manner. There is no listener that will execute after one step is completed, but next step is not yet started. If there is one, please point me out, and otherwise, would you consider adding a listener like that? I could probably try and make the PR if this feature is accepted.

[fmbenhassine]

Thank you for opening this issue.

StepExecutionListener does not work, because in afterStep, step is not acutally completed yet, because it's exit status can still be changed, and status in the DB table is not COMPLETED, but STARTED.

The issue is with the current implementation of that callback listener in Spring Batch, which is incorrect. According to the contract of that method which states that that method is Called after execution of the step's processing logic (whether successful or failed), the status (both in memory and in the DB) should not be STARTED at that point, but rather a non-running status. The end time should be set at that point as well (as reported in #3846). So I believe this is a bug and not a feature that should be requested.

Once this is fixed, I think you can implement your requirement with a StepExecutionListener. Do you agree?

[cezarykluczynski]

@fmbenhassine Yes, if status was non-running in both memory and DB, that would solve my problem. However, the afterStep method returns an {@link ExitStatus} to combine with the normal value, which gives the chance to overwrite the original exit status. Therefore, if non-null status is returned, one more save in the AbstractStep around line 268 is needed (hopefully it's that simple). I'm also not sure if that would not break some assumptions other people are making about how Spring Batch works here, even if they rely on a bug.

[gdupontf]

Forgive me if I'm wrong, but isn't the same problem present at the job level?
I had the same behaviour using JobExecutionListeners.