Bugzilla – Bug 5690
Flow/Split transitioning & termination not fully defined
Last modified: 2015-09-03 20:56:26 UTC
See public ML discussion: "DISCUSSION: Dealing with the fact that Flow and Split Transitioning incompletely defined in 1.0 Maintenance release spec errata"
I consider this still up for discussion..more so than usual.
I'm writing it up though since I took the step of including it in my draft PDF.. so it's "advanced through the process" in that sense.
1) Replaced "Split termination processing" in Sec. 8.4. with new subsection:
8.4.1 Split Termination Processing - Incomplete
The effort of the initial 1.0 final release specification to define split termination processing is recognized as incomplete. This is related to the recognition that flow transitioning is incomplete (section 8.9.5).
As such, there is no well-defined mechanism for “passing back” status from the individual child flows of a split and aggregating them into a status at the split level. There is, accordingly, no termination based on the status of the constituent flows performed after a split execution.
However, the implementor must be aware that a split may have a child flow where the flow itself or a flow’s child (step, decision, etc.) causes the job execution to terminate. This could be via an end, stop, or fail transition element, or via an unhandled exception.
In such a case the job should then cease execution before transitioning past the current, containing split, on to the next execution element.
Typically only one such element (in one single flow) would terminate job execution, with a corresponding batch and exit status that would then be set by the implementation as the job-level batch status and exit status, since typically the whole split would be intended to complete.
The spec does not make an effort, then, to define the outcome if more than one flow within a split produced a terminating status. A suggestion, though, is that a FAILED batch status should be given preference to STOPPED, which should be given preference to COMPLETED status, and a natural corollary might be to bubble up the associate exit status as the job-level exit status as well.
2) Added new subsection 8.9.5 to new section 8.9 (which was added for other bugs)
8.9.5 Flow-level Transitions Undefined
It is recognized that the specification is incomplete with respect to how exactly flow transition elements are evaluated. Though the list in section 10.8 has an assertion in rule 3.e. that suggests using the exit status of the last contained execution element as a flow-level exit status, this does not seem to be a complete definition. For example, what if the last execution element within the flow is a split?
This might be rectified in a later revision of this specification. In the meantime it is suggested to avoid using flow-level transition elements in light of this ambiguity.
3) Added this sentence to the end of Rule 3.e. within section 10.8:
(Note that Section 8.9.5 describing a problem such that this statement is considered incomplete.)
Section 8.4.1 & Section 8.9.5
I don't think we can leave the spec saying "this section is incomplete". We need to have an answer of some kind in order for it to be a final version of the spec. Either we disallow splits or we allow them and define the rules for it.
It seems too heavy-handed to react to an incomplete specification by adding an errata saying this is flat-out illegal.
Maybe saying "this section is incomplete" is the wrong way to package it, but I feel like it is legitimate to say "the behavior with this combination of elements is undefined".
I think we need to do something here.
Another option might be to first try to reach consensus on what flow/split transitioning should entail, and then decide whether it seems legitimate to add that as a spec errata or not. I took the approach I did since my guess was that whatever we'd come up with would be hard to "sell" as purely an errata, but that's just my opinion.
Since this has been left "undefined", I can't see what we could test here. Closing.