Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

StepExecution.getEndTime() returns null in StepExecutionListener.afterStep() #3846

Closed
HomoEfficio opened this issue Feb 8, 2021 · 4 comments
Labels
has: minimal-example Bug reports that provide a minimal complete reproducible example in: core type: bug
Milestone

Comments

@HomoEfficio
Copy link

Bug description

StepExecution.getEndTime() invoked inside StepExecutionListener.afterStep() returns null.

It should return a valid time, according to the API docs which says below:

(StepExecutionListener.afterStep() is) Called after execution of step's processing logic (both successful or failed).

I already checked the similar isssue, #2710, but the comments in that issue do not seem to be consistent with the API docs.

Environment

Java version: AdoptOpenJDK 11
Spring Batch version: 4.3.1
Spring Boot version: 2.4.2

Steps to reproduce

Download and execute this spring boot application: https://github.com/HomoEfficio/scratchpad-spring-batch

The console result is like below:

[  restartedMain] i.h.s.s.s.SpringBatchSampleApplication   : Started SpringBatchSampleApplication in 0.812 seconds (JVM running for 1.259)
[  restartedMain] o.s.b.a.b.JobLauncherApplicationRunner   : Running default command line with: []
[  restartedMain] o.s.b.c.l.support.SimpleJobLauncher      : Job: [SimpleJob: [name=Sample Job]] launched with the following parameters: [{}]
[  restartedMain] o.s.batch.core.job.SimpleStepHandler     : Executing step: [Sample Step]
[  restartedMain] i.h.s.springbatch.sample.BatchConfig     : Sample TaskLet executed
[  restartedMain] i.h.s.springbatch.sample.BatchConfig     : stepName: Sample Step
[  restartedMain] i.h.s.springbatch.sample.BatchConfig     : stepStartedAt: Mon Feb 08 11:36:12 KST 2021
[  restartedMain] i.h.s.springbatch.sample.BatchConfig     : stepEndedAt: null  ===============> SHOULD BE A VALID TIME
[  restartedMain] o.s.batch.core.step.AbstractStep         : Step: [Sample Step] executed in 10ms
[  restartedMain] i.h.s.springbatch.sample.BatchConfig     : jobName: Sample Job
[  restartedMain] i.h.s.springbatch.sample.BatchConfig     : jobStartedAt: Mon Feb 08 11:36:12 KST 2021
[  restartedMain] i.h.s.springbatch.sample.BatchConfig     : jobEndedAt: Mon Feb 08 11:36:12 KST 2021
[  restartedMain] o.s.b.c.l.support.SimpleJobLauncher      : Job: [SimpleJob: [name=Sample Job]] completed with the following parameters: [{}] and the following status: [COMPLETED] in 21ms

Expected behavior

StepExecution.getEndTime() invoked inside StepExecutionListener.afterStep() should return a valid time instead of null.

Minimal Complete Reproducible example

https://github.com/HomoEfficio/scratchpad-spring-batch

@HomoEfficio HomoEfficio added status: waiting-for-triage Issues that we did not analyse yet type: bug labels Feb 8, 2021
@fmbenhassine fmbenhassine added the has: minimal-example Bug reports that provide a minimal complete reproducible example label Feb 8, 2021
@arun406
Copy link

arun406 commented Feb 15, 2022

is there any update on this bug. I am also facing same issue.

@fmbenhassine
Copy link
Contributor

Thank you for opening this issue.

I agree, StepExecutionListener#afterStep is called after the step is finished (successfully or with a failure), so the end time should be set at that point. Moreover, this is currently not consistent with JobExecutionListener#afterJob, which is called after the end time is set (so the end time will be set when requested in the listener).

I see listeners as pre/post processing injection points, and not part of the actual job/step execution itself. A typical example for such listeners is timing a job or step, which is impossible if the end time is null in afterStep or afterJob.

This will be a minor breaking change, so I will plan it for one of the upcoming minor versions.

@fmbenhassine fmbenhassine added in: core and removed status: waiting-for-triage Issues that we did not analyse yet labels Jun 15, 2023
@fmbenhassine fmbenhassine added this to the 5.2.0 milestone Nov 20, 2023
@Kyoungwoong
Copy link
Contributor

Kyoungwoong commented Dec 7, 2023

can I take this issue?

@fmbenhassine
Copy link
Contributor

@Kyoungwoong Sure. Thank you for your offer to help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
has: minimal-example Bug reports that provide a minimal complete reproducible example in: core type: bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants