Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow setting a state machine to some intermediate state #72

Open
husam-e opened this issue Feb 21, 2024 · 2 comments
Open

Allow setting a state machine to some intermediate state #72

husam-e opened this issue Feb 21, 2024 · 2 comments

Comments

@husam-e
Copy link

husam-e commented Feb 21, 2024

In scenarios where state machine entities are persisted and outlive a host's memory, and then are later retrieved to act upon, it would be helpful to be able to efficiently load the state machine logic for its current state, to know what it can do and fire off tasks and potentially transition to the next state.

So something like func (sm *StateMachine[S, T]) SetState(state S), to immediately put the StateMachine into the state the entity is in, and act on it from there.

Is there appetite for something like this, and are there any concerns or limitations preventing it from being added?

@qmuntal
Copy link
Owner

qmuntal commented Feb 25, 2024

Hi @husam-e. Thanks for submitting this proposal.

What you are asking is already possible using a state machine with external storage:

var state State = "A"
sm := stateless.NewStateMachineWithExternalStorage(func(_ context.Context) (State, error) {
	return state, nil
}, func(_ context.Context, s State) error {
	state = s
	return nil
}, stateless.FiringQueued)

...

state = "B"

Does it work for you?

@husam-e
Copy link
Author

husam-e commented Feb 25, 2024

Thanks @qmuntal ! I see that can work for one particular entity at a time, where the stateAccessor delegates to a DB fetch or some object that reflects the persisted state. However my thinking is to use the constructed state machine in a more "functional" way, so that I can reuse the same instance as a blueprint for many different entities at any point in time, that can all be in different states.

So thinking of constructing the state machine definition once, holding that in memory, then when handling requests for certain entities in a specific state, identifying what is possible at that state from the state machine defined and then executing those triggers/tasks. And then doing the same for another entity that could be in a different state.

With the current implementation, I think I'd have to reconstruct the state machine for each entity I operate on (so every time I want to do something essentially), and tie the stateAccessor to wherever that particular entity is stored. There may be some performance consequences to that?

(Hope this makes sense!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants