Is there a pattern for "resetting" a machine with an 'error' or 'done' status?

[lnhrdt]

When a machine enters an error status (e.g. an exception was thrown) or a done status (e.g. transitioned to a final state) is there an established pattern for resetting the machine?

I've tried calling .start() on the actor but in my testing it seems to replay events that caused an exception (leading to an error status). I couldn't find any examples or docs on ways to "reset" a machine so I thought I'd ask here.

[crishoj]

Are your error / done final states?

I am not aware of any way to restart a terminated actor. I suppose the intended pattern is to create and start a new actor.

On the other hand, if your error/done states are not final, you can add transitions and actions to return to the initial state and clear the actor context.

[lnhrdt]

Thanks for your perspective @crishoj!

Are your error / done final states?

I actually was being intentionally specific when I called them statuses not states. I'm referring to the status that is given on on a machine snapshot. For example in React:

const [snapshot] = useMachine(myMachine)
console.log(snapshot.status) // Possible values: 'active' | 'done' | 'error' | 'stopped'

I'm trying to build a user experience that allows the user to restart a machine that unexpectedly entered an error status, or restart a workflow that expectedly entered a done status. I know I could just not use final states at all to solve for the done status scenario, but that doesn't help me much for handling the error status. For example if an uncaught exception was thrown somewhere in the machine, it would enter the error status.

The approach of creating and starting a new actor doesn't fit well when using XState with the @xstate/react package, unless I'm missing something there.

Any ideas on that? Anything I might be missing here?

[crishoj]

This is beyond my knowledge of XState. Perhaps @davidkpiano can chip in?

I can add that in my use case, errors are handled by onError transitions to a non-final Failure state.

[lnhrdt]

I can add that in my use case, errors are handled by onError transitions to a non-final Failure state.

Thanks for sharing that idea. We tried that approach too. In theory it could work for us (and we do exactly that for the errors that we expect). But in practice, trying to wrap every possible piece of code that can throw an error (network requests, libraries, etc) with a try/catch was problematic because:

1. It made our machines much harder to read. Not just the addition of the try/catch but the transitions to a (non-final) failure state really increased the size of our machine definitions and made it hard to understand.
2. It was prone to mistakes (we can easily overlook scenarios that can throw errors).

When we realized that the 'error' status is triggered by uncaught exceptions, relying on that status to gracefully handle truly unexpected errors seemed like a possible great approach, but we couldn't figure out a nice pattern to reset the machine (in support of a user experience).

Perhaps @davidkpiano can chip in?

Yes, would love your perspective David!

[jinjin99]

So if the machine's status is error, is it not possible to restart the machine? 🤕

[davidkpiano]

I suppose the intended pattern is to create and start a new actor.

Yes, this is the intended pattern.

So if the machine's status is error, is it not possible to restart the machine? 🤕

What is the expected behavior? Do you want to go back to the initial state?