What happens when a state timeout is met?

[wmedvede]

Hello @tsurdilo and all of you guys working on the spec!

As a newcomer to the spec when I started the implementation of the timeouts for some of the states, the following question came to my mind: What happens when a timeout is met?

To illustrate the question I’ll use the Event and Callback states, that I believe fall more or less into the same use case.

Event state:
Imagine that we have a SW with an event state used as an intermediate state.
(I have seen that there are ongoing discussions around this particular state, but I believe the question still apply)

And at some point in time, for instance the eventTimeout is met. If we look at the spec, It suggests that: “the event state should transition to the next state or end the workflow instance in case it is an end state without performing any actions.”

In this situation, in the “NextState” pointed by the transition, we really don’t know from which scenario we have landed.

1. An event has arrived, and thus we moved to the "NextState", so we probably we have the information/data we were waiting for to continue with the happy path

2. The event never arrived :(, we don’t have the information/data we were waiting for and thus we must follow a kind of “particular” path.

Which means that the logic of knowing if we are in 1) and 2) must be implemented in the SW, probably by using a Switch state with dataConditions, etc.

Callback state:
Imagine now that we have a Callback state. Let’s say that the actions were executed successfully and now the state is in the callback event waiting stage.

In this particular case, I believe the spec is not specifying any particular semantic, but let’s say that we follow the specification/reasoning for the Event state and thus the SW should transition to the “NextState”.

So we fall again into the scenarios 1) and 2). In the “NextState” we should have a kind of logic for knowing what to do.

Note: In this particular case, since the spec is not saying what to do, a third option could be adopted, that is to simply “throw a kind of timeout exception” (implementor dependent) and follow the “onErrors” path.

Consider that the reasoning exposed above for the eventTimeout could make sense also for the “actionExecTimeout” or the "stateExecTimout" around the different states. (not only the states that receives events)

Switch state:
However in this particular state, when we have eventConditions it’s clearly stated that by using the defaultCondition we can establish the path to go when the evenTimeout is met. Everything is under control!

Proposal:
Finally, the question that comes to my mind is, could it make sense to consider the following "simplification/change" at the "timeouts" configuration?

"timeouts" : {
        "stateExecTimout":  "as it is now"
        "eventTimeout": "as it is now"
	"actionExecTimeout": "as it is now"

	"transition": "where to go when the timeouts are met"
		This is an optional piece of the timeouts configuration. 
		When configured, and any of the timeouts are met, the workflow will move to the configured state.
                

	"end:" : "stop the workflow here". 
                 This is an optional piece of the timeouts configuration.
                 When configured, and any of the timeouts are met, it basically establishes that the SW Workflow execution will be finalized.
		 
        
        If none of the "transition" or the "end" fields are configured, then a kind of "timeout error/exception" is raised and the "onErrors" path is activated.
        Which basically models a kind of "fail-fast" approach.
}

Considering that we have three kind of timeouts that might occurs, and that the occurrence of the potential timeouts also vary per state type.

Do you think this of "simplification" could make sense? and have en equivalent timeouts handling for all the states and situations?

[antmendoza]

Hi @wmedvede, thank you!

I think you've made a very good point here. I like the idea of having the transition as part of the timeout definition, I think that would make the DSL more clear.

From the specification I understand that we can specify timeouts at state-level or at workflow-level, if timeouts are defined at workflow-level (top-level) states that do not have timeout defined will inherit it. https://github.com/serverlessworkflow/specification/blob/main/specification.md#Workflow-Timeouts

I have one doubt. When timeouts is defined at top-level, would it makes sense to specify a value for timeouts.transition? by doing that timeouts.transition is going to be the same across several workflow states (of the same type)

The way I see it is that transitions have more to do with the state's inputs/actions/outputs than with the type of state.

[tsurdilo]

Sorry I dont understand question, timeouts should be handled by error handling after all retries are exhausted.

[wmedvede]

Good point. I believe this last statement is missing in the spec "timeouts should be handled by error handling after all retries are exhausted"

But even so, I think we have some cases that are not clear to me.

Take look at Event Timeout Definition section please.
Here the spec says:

"If the event state is not a workflow starting state, the eventTimeout property is relative to the time when the state becomes active. If the defined event conditions (regardless of the value of the exclusive property) are not satisfied within the defined timeout period, the event state should transition to the next state or end the workflow instance in case it is an end state without performing any actions."

Here, we have basically that if no event arrive, the workflow should transition to the next state. Which means that in the "next state", in general you don't know if it you are there because "events have arrived" or "becasue the eventTimeout" was met. So in the "next state" you must always analyze the data to know from which scenario you have arrived.

I conclude that we have for example at least three different behaviors for the eventTimeouts.

1. Event state: "if the eventTimeout is met move to next state" (if a transition was configured)

2. Switch state with eventConditions: "if the eventTimeout is met, activate the defaultCondition"

3. Callback state: "if the eventTimeout is met", following your last statement, activate the error handling.

Is this correct?

[ricardozanini]

@tsurdilo @antmendoza I think we can rewrite the excerpt quoted by @wmedvede to make it more clear that in case an event is not consumed by the timeout policy, that could lead to an error branch.

"If the event state is not a workflow starting state, the eventTimeout property is relative to the time when the state becomes active. If the defined event conditions (regardless of the value of the exclusive property) are not satisfied within the defined timeout period, the event state should transition to the next state, end the workflow instance in case it is an end state without performing any actions, or be handled according to the onError definition."

It makes sense to have a branch where the user won't like to "do nothing, just transition". There are cases where an error should be thrown. Based on what @wmedvede wrote, it seems to me that this path is not clear in the spec. I can send a PR if we agree that we should clarify this part.