search

serverlessworkflow / specification

Contains the official specification for the Serverless Workflow Domain Specific Language. It provides detailed guidelines and standards for defining, executing, and managing workflows in serverless environments, ensuring consistency and interoperability across implementations.
http://serverlessworkflow.io
Apache License 2.0
745 stars 147 forks source link

Remove `Schedule.On` property #971

Closed cdavernas closed 3 months ago

cdavernas commented 3 months ago

What would you like to be added:

Remove the On property from the WorkflowSchedule object.

Why is this needed:

The On property duplicates the functionality of a Listen task placed as the first task. Retaining the On property may lead to confusion regarding how to properly configure workflows that start in response to events. It also risks creating inconsistent or unintended workflow behaviors when an event-based schedule is defined and then begins with a Listen task.

cdavernas commented 3 months ago

@JBBianchi @matthias-pichler-warrify @fjtirado @ricardozanini What do you guys think?

ricardozanini commented 3 months ago

So, if I have a starting task with Listen and a Schedule, will the workflow start after receiving the event, respecting the schedule? It sounds reasonable to me to remove a duplicated property. Today, the Schedule.On seems to work more as a shortcut, but adds complexity to the implementation when the workflow starts with a listen task.

+1

fjtirado commented 3 months ago

How do we differentiate between a workflow which first task is to wait for an event and a workflow that should be started through an event?

fjtirado commented 3 months ago

To be honest, I prefer to have Listen task behaving the same not matter where is located in the workflow and have a special keyword (schedule.on or staring.on) to indicate the workflow should be started upon reception of the event. Listen will always mean a workflow that has been started is waiting on that event. If it is the first state, it covers the case where the user start the workflow through regular trigger (usually a rest invocation) and the first thing the workflow will do is to wait for an event specifically directed to that workflow.

fjtirado commented 3 months ago

on the other hand, it seems most people intuitively understand that if the first task of a workflow is a listen one, it means that the workflow should be started when an event of that type is received. Whatever approach we took, it should be thoroughly documented.

cdavernas commented 3 months ago

To be honest, I prefer to have Listen task behaving the same not matter where is located in the workflow and have a special keyword (schedule.on or staring.on) to indicate the workflow should be started upon reception of the event.

It totally make sense, and you have made some very strong points in the private discussion we held this morning, the main one being the difference between scheduling the flow, which is a process hidden from the user, and between actively listening for events, possibly with timeouts, complex event processing and race conditions.

As a matter of consequence, I will close this issue and leave the spec as is, allowing users to address the two different use cases.

However, said use cases show differences that might be extremely subtle to newcomers and/or non-technical authors, and would therefore require clear examples, and exhaustive documentation.

I opened #972 to that purpose.