Spring Statemachine context variables not updating in action - spring-statemachine

Question

I am having some problems with Spring statemachine + Spring boot application.
I am using Redis for persistence, as in Event service demo. I have one action which is executed when state machine enters state 'VALIDATION'. In it, I modify extended state variables. Code example below is simplified, but tested:
This is main, calling method:
public void feedMachine(String event, int orderItem) throws Exception {
System.out.println("DEBUG FEEDMACHINE STARTED");
StateMachine<String, String> machine = persister.restore(stateMachine, orderItem);
machine.sendEvent(event);
System.out.println("DEBUG FEEDMACHINE... machine = " + machine.getUuid());
System.out.println("DEBUG FEEDMACHINE... variables = " + machine.getExtendedState().getVariables());
if (machine.getExtendedState().getVariables().containsKey("guard")
&& !machine.getExtendedState().get("guard", Boolean.class)) {
System.out.println("DEBUG FEEDMACHINE... guard = " + machine.getExtendedState().get("guard", Boolean.class));
throw new GuardedEventException();
}
persister.persist(machine, orderItem);
System.out.println("DEBUG FEEDMACHINE ENDED");
}
This is action:
#Bean
public Action<String, String> CustomerOrderValidatedEntryAction() {
return new Action<String, String>() {
#Override
public void execute(StateContext context) {
System.out.println("DEBUG ACTION STARTED");
System.out.println("DEBUG ACTION... machine = " + context.getStateMachine().getUuid());
int orderItem = context.getStateMachine().getExtendedState().get(ORDER_ITEM, Integer.class);
context.getExtendedState().getVariables().put("guard", false);
System.out.println("DEBUG ACTION... variables = " + context.getExtendedState().getVariables());
persister.persist(context.getStateMachine(), key);
System.out.println("DEBUG ACTION ENDED");
}
catch (Exception e) {
e.printStackTrace();
}
}
};
}
When I leave action, in feedMachine extendedState.getVariables does not contain guard and errors variable.
This is output:
DEBUG FEEDMACHINE STARTED
2016-08-16 11:46:17.101 INFO 26483 --- [nio-8081-exec-2] o.s.s.support.LifecycleObjectSupport : stopped org.springframework.statemachine.support.DefaultStateMachineExecutor#a85eba8
2016-08-16 11:46:17.102 INFO 26483 --- [nio-8081-exec-2] o.s.s.support.LifecycleObjectSupport : stopped ... / / uuid=336abc3e-708e-46ad-892f-5835b50713c8 / id=null
2016-08-16 11:46:17.102 INFO 26483 --- [nio-8081-exec-2] o.s.s.support.LifecycleObjectSupport : started org.springframework.statemachine.support.DefaultStateMachineExecutor#a85eba8
2016-08-16 11:46:17.102 INFO 26483 --- [nio-8081-exec-2] o.s.s.support.LifecycleObjectSupport : started ... / ORDER_RECEIVED / uuid=336abc3e-708e-46ad-892f-5835b50713c8 / id=null
DEBUG ACTION STARTED
DEBUG ACTION... machine = 336abc3e-708e-46ad-892f-5835b50713c8
DEBUG ACTION... guard = false
DEBUG ACTION... variables = {orderItem=0, guard=false}
DEBUG ACTION ENDED
DEBUG FEEDMACHINE... machine = 336abc3e-708e-46ad-892f-5835b50713c8
DEBUG FEEDMACHINE... variables = {orderItem=0}
DEBUG FEEDMACHINE ENDED
Any help would be appreciated. I am not sure if this is connected with Spring statemachine or with Spring beans or something else.
I apologize for primitive code (using println instead of log.debug etc.).
EDIT:
I finally found out where was the problem.
I was using in action context.getExtendedState().getVariables().put("guard", valid); instead of context.getStateMachine().getExtendedState().getVariables().put("guard", valid);. Now it works as expected. Problem was that those two variables lists were not same.
context.getExtendedState()'s variables list would get updated with "guard"
context.getStateMachine().getExtendedState()'s variables list would not get updated.
However, after creating minimal working example (only 3 states instead of 15+, no nested states), it was working correctly with context.getExtendedState().getVariables().put("guard", valid);.
I also checked several days ago whether context.getExtendedState() and context.getStateMachine().getExtendedState() are same, and I concluded that they were.
This seems to me as a bug.