State machine sub-regions do not resume from last state after restore from persistence

[razmanolescu]

Problem statement

Issues

• Using default configuration (with persistence provided by JpaRepositoryStateMachinePersist), all sub-regions seem to be reset upon restarting the SM. It continues from the fork parent task and re-runs all children.
• It seems that if one of the sub-regions is in end-state and one is not (and persisted as such), the finalization (reaching end-state) of the latter will not trigger transition to join state and SM is stuck.

Expectations

• The expectation is that all sub-regions current states are persisted by default. Once a SM is acquired from persistence source, it should initialize all sub-state current states correctly and begin transitioning
• If one or more forked regions are saved with end-state, restarting parent SM should not inhibit transitioning to join-state, if remaining regions reach end-state.

Observations

It appears that the current state of each sub-region is persisted using the parent context (except in the case of initial state). This in turn overwrites the last sub-statemachine state, instead of being additive. This works on explicit persistence of entire SM, so it may be that there might be an issue with context building.

Please see repo with example here

Please let me know if any additional details or setup support is required.

[razmanolescu]

Bump

@jvalkeal, do you know if there is a known workaround for this?

[simbuatgit]

@jvalkeal Could u update on this issue. I am facing the same issue in implementing SM .

[jvalkeal]

@simbuatgit are you also using persistence to db/jpa? I've been looking this and there might be an issue with persistent context as most of a persist/restore tests are using in-memory structure(to make tests faster and be outside of an external structure).

[jvalkeal]

Think I finally found a probable reason for this issue. That runtime persister component with regions creates different entries(one for every region aka root, and childs in substate) in a DB while restore then how it's done expects contexts to be in one one entry. I'm going to see this a bit further.

[jmruvalcabav]

@jvalkeal do you have a workaround for this?, thanks!

[ShvetsovDV]

@jvalkeal I think, for reason this problem, we need to fix two bags in AbstractPersistingStateMachineInterceptor: 1. definition of real "childRefs" for orthogonal states Here we need to look at the line 171. I'am think condition "stateMachine.getState().isOrthogonal()" is unnecessary. 2. definition of real identifier of state machine for context The fact is that all changes are saved for the main state machine(with a main state machine id). We need to fix it.

You can see my solution at https://github.com/ShvetsovDV/spring-statemachine/commit/4837d83307b096c1d45a1b732da26736b55a0a2b

And second part of fix it is edit resetStateMachine in AbstractStateMachine like this https://github.com/ShvetsovDV/spring-statemachine/commit/e81339948811a4b4658329407e432a356f1595c7

[wonderslug]

Wondering what the state of this is? Im encountering this now and it would be nice to get a fix in.

[ShvetsovDV]

We have been using this fix in our own repository for several months now.

пн, 4 апр. 2022 г., 18:54 Brian Towles @.***>:

Wondering what the state of this is? Im encountering this now and it would be nice to get a fix in.

— Reply to this email directly, view it on GitHub https://github.com/spring-projects/spring-statemachine/issues/811#issuecomment-1087729101, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOOBXPQMOJOVJZTTUZXWXO3VDMGC5ANCNFSM4I3S447Q . You are receiving this because you commented.Message ID: @.***>

[jenyayel]

@jvalkeal did you have a chance to look into this? I don't mind helping with the issue, but I would happy to some guidelines, especially if you made some progress on it.

P.S. I went over related issues and looked to the proposed fix by @ShvetsovDV