Leading with node with a wait about goflow HOT 5 CLOSED

Not obvious what the correct behaviour here is. Let's suppose an entry node has a few actions and a wait, so it's events are going to be:

1. action_event1
2. action_event2
3. msg_wait

But our caller is starting with these events....

1. set_environment
2. msg_received
3. something_else

What is the correct event timeline?

from goflow.

Agreed that if there's actions to take prior to the wait it might be a bit different. This arises from migrating previous ruleset-first flows that are meant to handle an inbound message from a trigger. Perhaps it's different if it leads with a wait with no actions?

from goflow.

It does kinda make sense that if you want your wait to not actually wait but "consume" the initial message then it should be the absolute first thing in the flow..

I guess there's also a larger question of whether waits and the event they're waiting for have to be beside each other in the event timeline, or whether waits can pick from a set if events.

from goflow.

We have implicit behavior in our current flows now right? IE, if a flow's first node is a split on @step.value then we consider it having a wait..

Seems we can make that more explicit in the new engine, as in whether that node has a wait or not.

I think waits currently have a way of immediately determining whether they should end. This is the case for flow waits for example, where a subflow may have run to completion in an action before the wait is even reached. So in that way this seems very similar.

I wonder if maybe we should change the model for waits and resumes a bit that happen inline. For example, maybe when a subflow is called that actually CREATES a resume event that is then processed by the wait when it is reached. That would then remove the need for the special casing for waits, essentially they would figure out if they can resume where they are immediately based on what resume events exist perhaps?

from goflow.

It definitely feels slightly weird to me to have waits act differently if they are the first node vs not. I think that is especially weird in the new world where nodes can actually have actions on them. So what would be the rule then, nodes with no actions and wait that are the first node will "ingest" the first incoming message, but if it has actions or if there is anything else then it won't and will wait for the next incoming message?

That feels weird to me though I'm not coming up with anything better, just from a generic flow perspective that feels odd. Is this maybe special behavior of the msg_wait itself? In that it looks back to see if there were say any outgoing messages sent after the last msg_received and if not then treats that message as its resume event? That would make the behavior specific to msg_wait which will feel more correct at least.

from goflow.