Atomic produce and consume actions

[cdavernas]

What would you like to be added:
Atomic produce and consume actions, meaning splitting the actual event action into two new actions: produceEvent and consumeEvent.

Why is this needed:

• Allows for consuming without producing
• Allows for producing without consuming
• Easier to understand
• More ubiquitous

[ricardozanini]

@cdavernas, can you evolve a little bit your description (maybe including an example)? Not sure if I understood. We already have the produceEventRef and consumeEventRef in the EventAction: https://github.com/serverlessworkflow/specification/blob/main/specification.md#EventRef-Definition

[cdavernas]

@ricardozanini We do, but the produceEventRef property is required: no way to just consume an event. I don't see why I should have to produce a bogus event just to consume one. I get the 'asyncOperation' rationale behind it, but it is too restrictive IMO, especially in an event-driven world where the consumption of an event is the topmost priority => the consumption of an event drives it all.

We could just mark that property as non-required, but then the actual objet gets confusing with different properties that do the same thing: reference an event.

Example of what I'm proposing:

...
actions:
- name: Notify User about completion
  eventRef:
    refName: MyProducedEvent
    kind: produce # *
    data: {
       ...
    }
- name: Do something else
  functionRef: a-test-function
- name: Wait for something to happen
  eventRef:
    refName: MyConsumedEvent
    kind: consume# *
    dataFilter: {
      ...
    }
...

• Here we could:

a. Determine the action of the eventRef by consulting the eventDefinition's kind property => bad for schema, as we loose that discriminator for produceEvent and consumeEvent properties, which differ

b. Remove the (IMO useless) kind property on the eventDef, and move it to the eventRef object => easy for schema, as it is our discriminator property. Plus, why should I have to repeat the definition of the same event if I want to both consume and produce it?

[cdavernas]

I would as well propose to remove the non-ubiquitous, obsolete invoke property on the eventRef. There is no sync/async paradigm here, it's an abuse of language applied to a non-applicable "async function" concept.

If need be for that concept, you can achieve it yourself by assembling one produce event and one consume event actions.

[tsurdilo]

Think the reason for this is the event definition "source" property. If its consumed event then this has to be set to match the source where to consume from. if it's produced then runtime has to set the source.

so kind is "kinda" hehe, needed imo unless we say its not used when producing this event which is imo worse user experience maybe. i am not sure in how much % of cases you would consume and produce the exact same event definition, can you show example?

[cdavernas]

Think the reason for this is the event definition "source" property. If its consumed event then this has to be set to match the source where to consume from. if it's produced then runtime has to set the source.

Well, that was another of my concerns, actually. IMO, source should NOT be required when consuming. You could very well filter by source and/OR type.

[tsurdilo]

source is required attribute by CE https://github.com/cloudevents/spec/blob/main/cloudevents/spec.md#required-attributes

[cdavernas]

i am not sure in how much % of cases you would consume and produce the exact same event definition, can you show example?

Well, it's not a personal use case, just a reasoning, but I guess something like: to consume a "Hello" event from peers, shape it, then route it down to another group of peers: only the data would have changed

[cdavernas]

source is required attribute by CE https://github.com/cloudevents/spec/blob/main/cloudevents/spec.md#required-attributes

@tsurdilo Yes, but we are speaking of consuming (not producing) events: it's not because the spec mandates that CE must have a source that we should force user to filter on it!!! Otherwise, we should also add specVersion and id.

[tsurdilo]

I think event defs are cheap to define. we could either leave it as is and deal with the duplication thats currently a must, or add on event defs another enum type for kind maybe "dual" or something and then document that in source you would have to set both producers (since CE allows more than one). For this however we would also i guess need some sort of hook for the source produced by the runtime which to me seems not optimal.

[tsurdilo]

i personally like the eventRef kind lookup from the event def referenced, idk, seems natural to describe imo
think it also helps with being able to switch out event defs if you want to consume from test sources for testing idk

[cdavernas]

@tsurdilo yeah maybe, it's not the point of my feature request anyways. I just think that there is no added value to know that an event is gonna be consumed or produced in other places than in the action, so IMHO it's an obsolete property. But then again, doesn't really matter either, so let's leave it if you guys think it adds readability ;)

[tsurdilo]

ok :) from the eventRef perspective if its more clear to have "produceEventRef" and "consumeEventRef" or similar, yeah thats fine imo.