Example claims subscribe listener can be async

[theluk]

xstate/examples/mongodb-persisted-state/main.ts

Line 29 in 12bde7a

actor.subscribe({

Hello,

based on this example we decided to go with xstate, but unfortunately it seems to be a false claim.

Even though in this example a listener is async, the subscribe method does not seem to await it.
This results in very weird db behavior, probably dead locks, but we had to do some wacky work around with queues and setTimeouts.

I would suggest to remove the async listener from the example.

[theluk]

To reproduce, we use postgres with hasura, we have a machine with quite a few states and events. When we start the machine, it basically runs in a single tick. Sometimes there can be errors, and then the machine is stopping, starting a HITL process. We used subscribe to react to the state changes and save them in the db. But because they are obviously async but the subscribe method does not support them, the machine runs, triggers like 10 different state changes, and then the event loop executes those 10 state changes in a potentially weird order and basically at the same time. Because the order of the promises seems undeterministic, the db often crashes, or at least hasura, because certain triggers on the db side expect a certain state transition, that in this case seems to not be guaranteed

[davidkpiano]

I refactored the example to a task queue, which would be the appropriate way to handle this to avoid race conditions.

[theluk]

Yes, but I would suggest not to use the actor.getPersistedState() here, as when the task queue executes the task, the state of the actor might be already somewhere else. The closure should consider only the snapshot.