Event state and multiplicity of events referenced

[mswiderski]

While looking at event state it defines onEvents which is a list of event actions that should happen plus it references an array of event definitions it should react to. So from user perspective it seems like two levels

• onEvents sort of means events to be listening for and perform actions on receive
• eventRefs are actual references to the events to listen for

The first problem I see is that the exclusive attribute is on the same as onEvents which in my opinion is correct as then it would apply to all items of the onEvents array. And by that I'd say OnEvent should have only one reference to event definition and not array.

From runtime implementation point of view event definitions can be different from following perspectives

• data format it comes with thus same actions won't be able to properly filter data out of events
• different integration like Kafka topic, MQTT topic, HTTP endpoint etc that would make it really hard and complex to have support like that

With these point in mind I'd like to suggest to change the OnEvents definition to have only one eventRef instead of the list as this will make it easier to consume from users of the workflow definition. Plus it will be really explicit how the exclusive attribute applies. As currently it is not rally known what should happen. Let's take an example

• there are 5 onEvents array items defined
• each of the items reference 3 event definitions
• exclusive attribute is set to false

would this setup mean that it will only continue if there will be 15 events received?

Changing to what I suggest it would be clear that having

• there are 5 onEvents array items defined
• each of the items reference 1 event definition
• exclusive attribute is set to false

it will only continue when 5 events are received and that each event definition can actually come from distinct channels and have their own specific data formats.

What are your thoughts guys?

[mswiderski]

Another alternative could be to make onEvents to be onEvent (one item instead of array) and then move the exclusive attribute to the OnEvent definition that would then apply to eventRefs and allow to define clearly the logic around handling events.

[tsurdilo]

@mswiderski

    The first problem I see is that the exclusive attribute is on the same as onEvents which in my opinion is correct as then it would apply to all items of the onEvents array. And by that I'd say OnEvent should have only one reference to event definition and not array.

I think there is a use case for having eventRefs as array and it has to do with correlation. Currently event definitions are domain-specific and referenced by name only. There is nothing to prevent me from defining:

  "events": [
  {
        "name": "MyEventA",
        "type": "my.events",
        "source": "/myevents",
        "correlation": [
          {
            "contextAttributeName": "someattributeA",
            "contextAttributeValue": "abc"
          }
        ]
      },
      {
        "name": "MyEventB",
        "type": "my.events",
        "source": "/myevents",
        "correlation": [
          {
            "contextAttributeName": "someattributeB",
            "contextAttributeValue": "xyz"
          }
        ]
      }
    ]

and then do:

 "eventRefs": ["MyEventA", "MyEventB"]

In this case its same event but different correlation defined.
Do you think this can work, meaning we say that ok it can be multiple only if its same event (type+source) or in this case should we use expressions to define this correlation instead?

[fjtirado]

@tsurdilo Since you mention action eventRef, although not related with this discussion, but following the simplicity spirit exposed by @mswiderski, I feel there is certain overlap between consumeEventRef action and Event and Callback states. I mean, I think we are already covering all scenarios with Callback and Event state (even if we remove onEvent from the latter), so, in my opinion, we will simplify the implementation a lot if we remove consumeEventRef from the spec. You can implement fire&wait scenario with a callback state. You can implement wait&fire with event state. wdyt? (appart that this post should be in a different thread ;))

[tsurdilo]

for eventRef action, consumeEventRef is needed to denote sync invocation of that action imo.
yeah there are some overlaps between things, but thats imo fine, eventRef action takes 2 lines of json/yaml compared to many more if workflow state is used

[fjtirado]

for the case described in the first line (I call it fire&wait event), it can be a Callback state where the action is a produceEvent one. It will be more or less the same number of lines than an OperationState with an produceEvent and a consumeEvent, and for some reason (this is pretty subjetive) I see flow clearer.

[hirenr]

So, do we have a conclusion. Its been some time since the last discussion.

[ricardozanini]

This is on our backlog to solve for 0.9, @hirenr. We are looking for contributions if you're willing to take this one. We can revamp the discussion. @cdavernas cc

[ricardozanini]

@mswiderski +1 to make onEvent a single entry rather than an array. For the exclusive use case, this can lead to misunderstanding for all the parts involved. I've opened a PR to introduce a more complex use case to this scenario (multiple onEvents, with multiple eventRefs): #594

[cdavernas]

@ricardozanini What about @fjtirado suggestion, which is IMO much more consensual: we keep the possibility to define an array of effects specific to one/many events (aka onEvent), but clarify how they be consumed?

[ricardozanini]

Yup, that was my first suggestion and the rationale behind the PR I sent yesterday. Although I like simple things and having onEvent not being an array would simplify the understanding. It's a trade off, and I'm happy with both paths. I would go either way. What we can't have is misunderstanding in the spec.

[cdavernas]

I totally agree with you, and remember having to come back and forth to TO at the time I implemented it on Synapse, because of lack of clarity. I'd be more than happy to have it written in stone before I get to refactor it, too 😆

[fjtirado]

Yes, same here, I have implemented it in three different ways in the last two days ;). Main doubt is the decision to wait for all onEvents or not (and if exclusive field also applies to that). And realizing that some users, when using different onEvents, might want to have the flexibility to use different exclusive values for the eventRefs inside the onEvents.

[cdavernas]

Closing this discussion as it applies to a discontinued version of the spec.

I invite all participants to take a look at the new DSL and open a new discussion or issue if any of the discussed problem persist!