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

Different behavior when interrupting a job, depending on the parallel flow order #3939

Closed
kkmikhaylova opened this issue Jun 13, 2021 · 2 comments
Labels
for: backport-to-5.1.x Issues that will be back-ported to the 5.1.x line has: minimal-example Bug reports that provide a minimal complete reproducible example in: core related-to: flow-definition type: bug
Milestone

Comments

@kkmikhaylova
Copy link

Bug description
Different behavior when interrupting a job, depending on the parallel flow order.
I am creating a parallel flow and trying to interrupt a job from one of them. Further behavior depends on the order of the flow inside the add() function. In one case, the job is finished immediately, in the other, all steps from another parallel flow are executed.

Flow parallelFlow = new FlowBuilder<SimpleFlow>("parallelFlow")
.split(new SimpleAsyncTaskExecutor())
.add(nonInterruptingFlow, interruptingFlow)
.build();

Environment
Spring Batch: 4.3.1

Steps to reproduce

  1. Create a job with two parallel flows, where the last flow in the list interrupts the job.
  2. Make sure that the job has finished after the interruption.
  3. Change flow order (now the first flow in the list interrupts the job).
  4. Make sure that all the steps of the job have been executed after the interruption.

Expected behavior
Same behavior after interruption.

Minimal Complete Reproducible example
springbatchdemo.zip

@kkmikhaylova kkmikhaylova added status: waiting-for-triage Issues that we did not analyse yet type: bug labels Jun 13, 2021
@fmbenhassine fmbenhassine added has: minimal-example Bug reports that provide a minimal complete reproducible example in: core labels Jun 25, 2021
@fmbenhassine
Copy link
Contributor

fmbenhassine commented Jun 14, 2023

Thank you for opening this issue and for providing a minimal sample. Nicely done!

Both jobs complete as expected with a STOPPED status, but indeed the finishedJob proceeds to the nonExecutableStep even though the flow was interrupted in the previous step. That should not be the case. Since those flows are running in parallel, the interruption order should not matter.

Edit: Attached original sample updated to v5

gh3939.zip

@fmbenhassine fmbenhassine removed the status: waiting-for-triage Issues that we did not analyse yet label Jun 14, 2023
@doontagi
Copy link
Contributor

Hi @fmbenhassine, I checked this issue. And I've made a fix PR #4567.
PTAL 🙏

@fmbenhassine fmbenhassine added the for: backport-to-5.1.x Issues that will be back-ported to the 5.1.x line label Sep 2, 2024
@fmbenhassine fmbenhassine added this to the 5.2.1 milestone Dec 17, 2024
fmbenhassine pushed a commit that referenced this issue Dec 17, 2024
Resolves #3939

Signed-off-by: Mahmoud Ben Hassine <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: backport-to-5.1.x Issues that will be back-ported to the 5.1.x line has: minimal-example Bug reports that provide a minimal complete reproducible example in: core related-to: flow-definition type: bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants