Stalled gateway <+> with incoming condition (v2.0.0rc0) about spiffworkflow HOT 2 CLOSED

This is replicable with the the following even simpler diagram:

Instantiated tasks (as opposed to task specs) are always part of a tree (even in the spec contains a loop). When branches of a gateway are merged, spiff looks for any tasks associated with that spec and waits to proceed until all the branches that contain the gateway reach the task.

This causes a problem here, because the the parallel gateway has two direct ancestors: the 'Set x" task and the exclusive gateway, and the latter can't be reached until the gateway is executed once.

I am not sure what the best way to deal with this case is, and resolving the issue will likely take some thought (I can think of a couple of potential solutions, but they'd require some testing to make sure they don't break other cases).

The working case is a decent workaround, but it is reasonable to expect that the diagrams that don't work would work, though this might not turn out to be a very easy problem to fix. We should either figure out how to make it work (the ideal resolution) without breaking anything else, or raise an exception to warn that it won't, as you note.

from spiffworkflow.

The problem above raised a long and intense discussion yesterday in our own team on the very same
topics which started from the assumption that it seems intuitively that the broken case should work.

After doing more researh on documentation material the BPMN norm 2.0.2 indicates in sec. 10.6.4 at page 293:

A Parallel Gateway creates parallel paths without checking any conditions; each outgoing Sequence Flow receives a
token upon execution of this Gateway. For incoming flows, the Parallel Gateway will wait for all incoming flows
before triggering the flow through its outgoing Sequence Flows

A cross check on Camunda 7 documentation / parallel gateway tells:

An important difference with other gateway types is that the parallel gateway does not evaluate conditions. If conditions are defined on the sequence flow connected with the parallel gateway, they are simply ignored.

The BPMN standard is seemingly ambiguous about the fact that the gateway triggers after waiting incoming flows while at the same time indicating that incoming conditions are ignored.
The Camunda 7 documentation provides the same information but insist more on the fact that incoming conditions are simply ignored.

After cooking all that together it looks like a possible implementation in SpiffWorkflow would consist in checking whether an incoming flow has a condition set on it or not. If this is the case it could just be simply ignored for a <+>gateway in state WAITING ?
This design looks in fact more consistent as it would behave the same as the working case above that triggers the activity even when an incoming condition is not fulfilled...

from spiffworkflow.