Order of Transition Elements Still Does Not completely adhere to documentation

[chpasha]

Bug description
The original issue was fixed here #3638 but the the way the DefaultStateTransitionComparator works is stll different from what documentation says:
it states that

The framework automatically orders transitions from most specific to least specific

but the javadoc in comparator says

If wildcard counts are equal then falls back to alphabetic comparison. Hence * > foo* > ??? > fo? > foo.

this looks wrong to me since foo* is more specific pattern then * so it should fire before. Consider situation where Step execution can return COMPLETED or COMPLETED_PARTIALLY (alongside other possible statuses) and those two completed states should lead to different flow then FAILED (or any other) but conditional flow

.start(mainWorkflowStep).on("COMPLETED*").to(step1)
.from(mainWorkflowStep).on("*").to(step2)

doesn't work as expected because * fires and leads to step2 even on exit statuses like COMPLETED or COMPLETED_PARTIALLY
Current workaround is to use ** instead of single * so that COMPLETED* is considered "more important"

Environment
Spring Batch version : 4.3.3,
Java version 11

Expected behavior
standalone * should be never first but always the last in the pipeline since it is a catchall pattern and any other pattern containing characters other than * is "more specific"

[fmbenhassine]

Thank you for opening this issue. We do not exclude that this could be a bug in Spring Batch. However, we would like to validate that with a minimal complete verifiable example.

Could you please take some time to create a minimal example that reproduces the problem? To help you in reporting your issue, we have prepared a project template that you can use as a starting point. Please check the Issue Reporting Guidelines for more details about this.

Thank you for your collaboration.

[chpasha]

Hi fmbenhassine,
here you go
spring-batch-mcve.zip

[robertmcnees]

Thanks @chpasha for the sample. I easily got it running on my machine and can see the issue. After entering my own issue #4456 that @hpoettker helped me sort out I came back to this and suggested a fix with a PR.

I was able to point your sample at my local Spring Batch build using this code and it should now have the expected behavior. There is also a new test testBuildWithDeciderPriority in FlowJobBuilderTests that should be a direct test as well.

Looking for feedback...