if event is triggered before state is transitioned, and this event trigger the state?

[elim19]

consider this situation:

1. OrderCreatedEvent is sent first
2. state a is transitioned to state b
   my question is will state b action b2Event be called since OrderCreatedEvent is already sent?

[cdavernas]

@elim19 No it would not. The event has been fired prior to listening to it, so only the next one would be caught

[tsurdilo]

Imho this is a great question and one you should definitely consider when picking the runtime for SW or decide what to do in case you are writing your own runtime.

It's important for any workflow runtime to have events being delivered async, meaning eventscan be delivered to the workflow execution while its performing some state.

Imho for many use cases it is not optimal to wait until exec is in state b until you actually start consuming events (so any so far delivered ones are thrown away).
Imagine your workflow execution is in state a, and event OrderCreationEvent comes in during this time.
Imho it would be wrong to not consume it at that point and wait for another order creation event when workflow execution comes to state b.

Currently as the spec is, it leaves it up to the runtime unfortunately but definitely something we can add (think "event handler functions").

There are many use cases, and your order example is very good as in the end user only creates a single order so does my workflow current state have to determine when this order is created. It only matters in many use cases that the workflow execution is started (when its not running it cannot receive any events). Also its up to runtime currently to de-dupe events, so for example lets say end user clocks the "order" button twice, would it generate two order events or one?

[cdavernas]

I agree the question is much more complex that I initially thought.

I however think that a workflow shoul not be collecting events passively before reaching a consumer, because first it creates a lot more issues than it solves and second is in most cases it should belong to another instance, and if the event is critical at any point in time, should instead be consumed by a workflow with a start event state

[cdavernas]

We could, however, add some consumer property to do so, but following your approach it'd then see it as an extension for the time being.
The async consume that you mention makes a lot of sense to me, and imho belongs to the discussion about atomic produce/consume actions

[tsurdilo]

This is really a runtime question than the spec question imo.

How the runtime interprets eventRefs="OrderReceived" can be implemented in different way. For example the runtime could create internal event handler for each/all different events defined in workflow and then start consuming them and keep them in an array for example as soon as the exec is created and starts (pop them off each time its consumed by a condition (event state for example)).

Either way, imho only listening to events when the exec is in a workflow state that waits for one and disregard any events before that state is very limited approach (it should be completely async imo but thats really again up to runtime impls to figure out and decide and not spec).

[tsurdilo]

Yeah, i think for big decisions like this where its most likely that different runtimes might want to implement it in different ways, additional features for these functions would be good to have in proprietary extensions depending on their impls, imo good idea.

[elim19]

Yeah, i think for big decisions like this where its most likely that different runtimes might want to implement it in different ways, additional features for these functions would be good to have in proprietary extensions depending on their impls, imo good idea.

@tsurdilo , how can I write my own runtime and replace it with the default one, is there an doc about it?

[tsurdilo]

Oh, honestly i would not look into creating your own workflow runtime, its just too much work unless you are serious about it.

Would instead look at whats out there now as far as runtimes that provide support out of box for SW (look at our website that mentions some like Synapse which is part of our github repo here , EventMesh Workflow, Kogito, FaasNet, OpenEnterprise, etc)

But note there are also very powerful programming-lang based workflow runtimes (things like Prefect, Temporal, Dapr come to mind) where running a DSL (that being SW or not) on top is in most cases pretty simple to build (see example here if that helps)

[tsurdilo]

The most important thing about picking a workflow runtime (this is my personal opinion only) is not the dsl or fancy features / editors whatever but its the runtime functionalities and capabilities, specifically performance, scalability and visibility.