While troubleshooting an apparent error just now, I noticed that all completed instances of a relatively simple process with an AND gateway had failed to execute both of its outgoing paths. The key factor here is that the process chains (unattended) all the way to a Terminate node, presumably because after the user submits their task in this subprocess, they're expected to chain into a followup task back at the parent level.
However I never realized this constraint was in place - that is, the process executes all possible chained paths (up to and including a terminate) before it will execute the other AND gateway outputs. This seems like a bug to me - but am I wrong? Has anyone else noticed this?
I was able to recreate the behavior with this very, very simplified example process, if anyone's having trouble picturing what I'm referring to:
Discussion posts and replies are publicly visible
I think you'll find some very interesting things. Accordingly, if you have an OR gateway, and all the outgoing flows are valid, then the documentation SAYS that one of the flows will be first randomly.
However, when I tried it, I consistently got one of the flows to finish first when attempting to create a race condition. (Fun to have a PM be your random number generator; sad it didn't work.)
Also, say you have AND with 5 different forms chained to it. Which will the user actually see?
AFAIK if you try to chain multiple out flows from an AND, all bets are off. That's sorta congruent with what we saw in my initial results here (though from an opposing perspective, as it were). The only frustrating part is that there's no mention of this in any of the official documentation, at least per what I could find with an initial check.
This is very interesting, I didn't about this behavior about AND condition. good to know.