Remove `Schedule.On` property

[cdavernas]

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]

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

[ricardozanini]

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]

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]

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]

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]

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.