Why Spring batch allows job without parameters to restart even if the job already completed successfullly?

[ELMORABITYounes]

Right now even if a job was completed successfuly, spring batch allow It to be restarted if It contains no identifying params as shown here:

if (!identifyingJobParameters.isEmpty()                                                        
		&& (status == BatchStatus.COMPLETED || status == BatchStatus.ABANDONED)) {            
	throw new JobInstanceAlreadyCompleteException(                                             
			"A job instance already exists and is complete for identifying parameters="       
					+ identifyingJobParameters + ".  If you want to run this job again, "    
					+ "change the parameters.");                                             
}                                                                                              

I am wondering why is that done like this? I mean if the job already completed why It does not throw JobInstanceAlreadyCompleteException? Shouldn't second job instance without param considered the same and hence not allow It to be restarted if already succeeded?

[fmbenhassine]

Is that really the case? This would be a bug. I did not test that (yet), but if you provide an example I will debug the case. No matter what the user provides, if the set of identifying job parameters ends up being the same (ie same hash), then the same job instance should not be restarted if it was completed in the previous run.

[ELMORABITYounes]

Hello @fmbenhassine,

Thank you for your response!

You can find an example for reproducing the issue here.

In that repo I created a generic api for running async jobs by the given job name, and what I am expecting is that when I run the same job twice I should get a JobInstanceAlreadyCompleteException exception if the job already completed successfully, but as I mentioned, if I don't provide any identifying parameter, the job always runs successfully even though it has already been completed.

In the branch job-run-with-identifiers you can see that when adding a default idenitifying parameter, the result is as expected and the expected exception is thrown.

As you can see in the above code snippet I shared previously It seems that this case was addressed specifically; that is why I thought maybe this is an intentional behavior and maybe there is some specific reason behind that.