Persist and restore state without recorded event history

[mc-allen]

Hello, thanks again for providing this library, it is super helpful!

In my use case, I frequently need to persist the state of my statechart from one thread and restore it another thread, on a different host, and the statechart will be "running" for very long periods of time, with many state transitions over the course of its lifetime. I see the event recording approach in the docs, but I'm wary of this approach due to the unbounded list of recorded events, and my need to frequently store these events and process them. Over time, this list could become very long and unmanageable/expensive.

An approach more like "Structure + configuration" or "Persisting state - serializing all internal data, active states, variables etc. from original StateMachine and applying them to restored one" would be more in line with what I need for my use case. Is there any way to approach this with what kstatemachine offers today? If not, this would be a very useful feature.

[nsk90]

This is the worst scenario for current event recording implementation(

It is rather difficult to correctly serialize whole state machine structure. Some of the library's features are really tricky to support, like:

• history pseudoState,
• undo stack,
• or custom state subclasses with mutable user defined properties

But I think it is possible to support "Configuration only + Persisting state" case with some limitations.

• Do you use some of those features?
• Would simple implementation (like persisting/restoring only active states configuration) fit your needs?

[mc-allen]

I am not using any of the features that you mentioned, and understand why those are tricky.

A simple implementation would fit my needs. I tried using the startFromBlocking() test method, but that also isn't quite right because it calls entry actions for each state, which isn't ideal when restoring IMO, as those can have side-effects that duplicate things that already happened pre-restore.

[nsk90]

I will check if I can implement such limited support. Thanks for the request!
If you have some other expectations (like de-duplication of entry events) feel free to write them here.

[mc-allen]

Thank you!
I'm not sure what you mean by de-duplication of entry events? I would expect that a restored state machine would not execute any actions when it is restored, only on the next event (as the entry must have been executed already when it entered the state prior to snapshot)

[nsk90]

yes we are talking about the same thing 👌