Bug: Persisted state deviation from schema

[ishabo]

Description

When using a persisted state loaded from local storage to hydrate the state machine, and schema changes are introduced to the state machine, such as a renaming of a certain node state, the state machine throws an error.

Expected result

I would expect the state machine to ignore the persisted state when provided, and log a warning instead.

Actual result

My react application throws an error and breaks the frontend. And the only way to recover is by clearing the local storage.

Reproduction

None

Additional context

No response

[davidkpiano]

I'm moving this to a discussion, as it is an enhancement to discuss rather than a bug, given that the same kind of problem will occur with any state restoration in general (with or without XState).

We can add basic validation that the state value is compatible with the state machine. The better long-term solution is to include some sort of "hash" of the machine to verify that the provenance of the state is from the machine that's attempting to restore that state.

I'm wondering if this should throw or warn, though 🤔 Warning gives the false sense that the state is "okay".

Maybe there should be a state.isFrom(machine) method or similar? cc. @Andarist

[ishabo]

Thanks @davidkpiano! Yeah after I created it I wasn't sure whether this should be a bug. But this is at the same time not an edge case. The snapshot could easily deviate in projects that have continuous deployment, and I found handling that kind of fatal error is quite awkward with react hooks.

But to your suggestion, state.isFrom(machine) seems like a neat decorator.

I am just looking to implement some custom solution at the moment. Would you in that case check the value that it matches existing states and nested states, and that context still has the same shape matching the initial context of the machine?

How would you in this case match a saved context against optional context keys that could potentially appear? What I mean by that, let's assume the machine had a context loading?: boolean .. which later changes to isLoading?: boolean .. loading the snapshot would in such case might work, because there's no way to match the shape of the context against the initial one unless isLoading is not typed as optional (assuming typescript is being used, which is still a problem in pure JS). I hope that makes sense.

On another note, how about using versioning (perhaps in addition to your suggestion)? I think this is quite useful pattern. Still the downside that I see is that devs will need to remember to update the version when anything is changed.

[davidkpiano]

Are you looking for a solution to convert a state to a "newer" state for a more recent version of a machine, or a solution to check compatibility for the state?

[ishabo]

I am looking for compatibility check to fall back to the initial state. Something like this:

const service = interpret(myMachine).start(previousState.isFrom(myMachine) ? persistedState : undefined);

This would suffice for what I am trying to do.

[Andarist]

While this might suffice from some simpler use cases, it won't be ideal for use cases when an actual migration of the data is required. I think this should be put in a broader perspective and we should holistically rethink and document how this kind of a thing is supposed to be handled by the developer as it's common ask. It's especially important for the workflow engine as it might build on top of those recommendations/possibilities.