Persisting a state *after* machine is settled

[ayashjorden]

Hi,
As a followup to the discussion on Gitter, it is still unclear how to persist a state of a machine after the machine has settled (finished processing all of the transitions/activities).

The Persisting State documentation provides the basic example but also includes a call to resolveState which I don't understand the explanation comment.

In my scenario, I run machines in an on-demand:

1. Create a machine and persist it
2. Receive an event for that machine (the API can receive events for multiple machines)
3. Re-hydrate the machine from storage
4. Send the event to that machine
5. Get the new-state, after the machine finished processing all transitions and activities
6. Update the new-state in storage.

A machine can run through several transitions before it finish processing all transitions and activities.
The following snippet is an excerpt of that flow:

    public async send(id: string, event: IBaseEvent) {
        this.logger.info(`Got event: ${JSON.stringify(event)}`);

        this.logger.info(`Reading state`);
        const machineState = await this.storageAdapter.getMachine(id);

        this.logger.info(`Creating state`);
        const previousState = State.create<IBaseContext, IBaseEvent>(machineState.state);

        this.logger.info(`${id} PREVIOUS state value: ${JSON.stringify(previousState.value)}`);
        this.logger.info(`Creating machine`);
        const machine = await this.createMachine(id, machineState.machineConfigId);
        this.logger.info(`Resolving state`);
        // Need some more detailed info on why this is needed
        const resolvedState = machine.resolveState(previousState);

        this.logger.info(`Creating the Interpreter`);
        let interpreter = interpret(machine);

        this.logger.info(`Starting the Interpreter`);
        interpreter = interpreter.start(resolvedState);

        this.logger.info(`Interpreter.initialized=${interpreter.initialized}`);

        this.logger.info(`Sending event`);
        const newState = interpreter.send(event);
        this.logger.info(`${id} NEW state value: ${JSON.stringify(newState.value)}`);

        this.logger.info(`Persisting state`);
        await this.storageAdapter.updateMachine(
            id,
            { state: JSON.stringify(newState.toJSON()) }
        );

        interpreter.stop();
        return newState;
    }

Getting the updated state from interpreter.send(event) may not result in the most recent state if the machine has still some processing to do (transitions and activities, actions or anything else from MachineOptions that runs longer).

In my use-case, I had to add a sleep to let the machine settle and only then get the state:

this.logger.info(`Sending event`);
interpreter.send(event);
await new Promise((r) => setTimeout(r, 10000));
const newState = interpreter.state; // Now the state is where I expected it to be

The ugly solution I found is:

        this.logger.info(`Sending event`);
        interpreter.send(event);
        let newState = interpreter.state;
        do {
            this.logger.info(`${id} still crunching activities: ${JSON.stringify(newState.activities)}`);
            await new Promise((r) => setTimeout(r, 1000));
            newState = interpreter.state;
        } while (Object.entries(newState.activities).some((v) => v[1]));

        this.logger.info(`${id} finished crunching activities: ${JSON.stringify(newState.activities)}`);
        this.logger.info(`${id} NEW state value: ${JSON.stringify(newState.value)}`);

I'd appreciate any ideas/feedback on the above,
Yarden

[Andarist]

Getting the updated state from interpreter.send(event) may not result in the most recent state if the machine has still some processing to do (transitions and activities, actions or anything else from MachineOptions that runs longer).

Actions are considered "fire & forget" so from our perspective they take near-zero time and are always considered as done after we fire them.

I would recommend using onTransition for this:

let newState
interpreter.onTransition(state => (newState = state))
interpreter.send(event);
await this.storageAdapter.updateMachine(
  id,
  { state: JSON.stringify(newState.toJSON()) }
);

This would "resolve" all sync transitions etc but if you have any async work that you need to await then you need to track it within your machine and only store the state when you know that all async work has been finished.

[ayashjorden]

My (root) machine is composed from actions (fire-and-forget) and services (either child Machines or async functions that return a result).
Is there a way to make interpreter.send(event) to optionally accept a waitForMachineToSettle parameter ?

Or, what are all the State variables that I need to check to determine if the machine is still processing transitions/activities or its done?

[ayashjorden]

interpreter.send(event) returns immediately, when the Machine may have not settled yet.

[Andarist]

Is there a way to make interpreter.send(event) to optionally accept a waitForMachineToSettle parameter ?

It's not possible because the interpreter doesn't know if you plan to return a value from your services or if those are long-lived jobs. The use case you are describing is pretty-specific and we wouldn't like to bake anything like that into the core. XState provides quite low-level & flexible building blocks - don't be afraid of building some abstractions around it.

As @davidkpiano said here:

there is no one-size-fits-all rehydration use-case.

[ayashjorden]

I agree, I'll follow on the other comment and look into state.children

[x-aaron-moore]

We are currently in the process of designing some services that will use xstate for state management. It has occurred to me that for this use case, it might actually make sense to write our own custom interpreter tailored for the necessity to persist and rehydrate and the different flavor of listening for events in that context. Having run across this thread, and noticing the similarity of your send function to the bare-bones custom interpreter in the docs, I just thought I might suggest that as one possibility (albiet, requiring more work).

[davidkpiano]

That's a good idea, since there is no one-size-fits-all rehydration use-case.

[ayashjorden]

I'll look into that, but its not clear to me what attributes I should monitor to determine if the transition has finished.

• What events did the current transition yield and we need to continue send them to the machine to advance it
• What actions should be executed (I see an example in the custom interpreter section
• What activities are currently running and how to detect they're done, see the OP for example of what I did, but not sure its availabe without the xstate.interpreter, probably need to look at the implementation.
• Invoked Services is expressed as State.activities, what else should I monitor to determine that current processing is finished?

I'm sure some experimentation is needed, but the above info will help clarify how to approach to develop a custom interpreter.

[Andarist]

its not clear to me what attributes I should monitor to determine if the transition has finished.

This is a little bit incorrect way of thinking - transitions always happen and finish synchronously, right away. There are no "async" transitions - your services can only respond with transitions to async events, but this is not the same.

What activities are currently running and how to detect they're done, see the OP for example of what I did, but not sure its availabe without the xstate.interpreter, probably need to look at the implementation.

I can't say from the top of my head but I would look into state.children and similar to see how this property behaves when invoked services finish their jobs. I would expect them to be just removed from the state - otherwise, we'd probably have a memory leak problem there.

[ConProgramming]

@ayashjorden Did you ever get this on-demand interpreter working? I have a similar usecase