Add support for a reset trigger (Add PermitAll support)

[gmoore-ra]

Hello Prasanna,

I would like to ask for support to create a way to reset to an initial state given specific triggers are fired. The reasoning here is that we have business logic that sometimes requires us to reset to an initial state, and we have this tied to a specific trigger. The issue is that in order for us to do a reset, we have to create a transition for every single state in our StateMachine to link back to the beginning with this trigger. However this is not an ideal situation, as the reset trigger(s) quickly make reading the more important triggers difficult when one or more lines are dedicated solely to permitting a trigger to move back to a specific state. As a result we chose to handle this ourselves using MoveToStateAsync after checking what trigger we fired, but this removes the autonomous aspect of LiquidState, and if we incorporate the same machine elsewhere, we would have to handle it there as well.

It would be nice if functionality could be provided to move to a specific state given a specific trigger, regardless of the state you are currently in. This way, the machine is easier to maintain and more autonomous, and can be incorporated in other services easily.

Is it possible for there to be functionality for this such as

public StateConfigurationHelper<TState, TTrigger> PermitAll(TState resetState, TTrigger resetTrigger)

That would then set these transitions for current states and potentially ones that were added later (or for the sake of simplicity this function is called last to set all states with this transition)?

Thanks again.

[prasannavl]

@gmoore-ra, LiquidState is meant to be just the core of statemachines, something over which task-specific state machines can be easily created. The idea is that LiquidState should be as generic as possible so that variants such as these can be easily written easily with abstractions.

You can easily write a very simple wrapper, which has the reset functionality that you require over the state machines that LiquidState provides by composing them.

Unfortunately, I don't see a lot of value in adding reset to the machine core. The effort required to create such machines is very trivial, while it will increase the complexity of the machine core.

That being said, currently there is not an easy way to do permit all, or to extend the machines using the StateMachineFactory itself.. (You could very well, just use your own machine class, but that wouldn't feel consistent.) Let me think over a PermitAll implementation that as you had mentioned, will indeed be useful. But I don't think a direct Reset implementation will be added to the core itself. One of the plans I have in mind is to better facilitate the activation of external machines (say, the simple wrapper classes that you'd create with reset, may be 'StateMachineWithReset' with the same factory.)

[prasannavl]

Hi, unfortunately I may not have the time anytime soon to do this, but I'm adding the design notes for future implementation, or if someone has the time to contribute or find use for this:

Design Notes:

• Currently, uses a dictionary to store internal Representations. Make a wrapper to hold this, and another set of Global representations which will include PermitAll.
• AddPermitAll to StateConfiguration class.
• Add Deny to StateConfigurationHelper to be able to ignore global permit-all configurations for specific states.

Flow:

• Use specific state configuration if available. When none exists with a successful predicate, try the global states, if they exist.
• Deny can be used to override global specifications.