Race condition issue in credit check example

[azasorin-rss]

I'm not sure if this is a bug or misuse on my part, so apologies if this is better suited as an issue instead of a Q/A; this felt like a safer place to start.

In the credit check example, I run into a problem where the calls to the observer's next() race each other when multiple snapshots are emitted close together (e.g. starting an actor and then sending them an event). This results in a stale state being saved to MongoDB instead of the latest state. This doesn't happen every time, but it feels like roughly a 50% chance every time there's a state transition for the saved state to be stale. I am using a simpler state machine that has no invokes or actions and state transitions are triggered purely by events being sent to the API. Eventually, I will want to add invokes, but they're not needed yet. The example code and the video going over the example don't seem to imply that this is an invalid use case.

I have a repository with a minimal recreation of the issue: https://github.com/gepenrose/xstate-exmple-issue
The README contains steps to recreate this manually via CURL commands as well as instructions for running a script that repeat the sequence of steps 100 times to show how inconsistent the results are. To summarize the steps to recreate the issue:

1. POST to the workflows API to initialize a workflow and get the returned workflowId
2. POST to the workflows API with a "SUBMIT" event
3. GET the workflow using the workflowId and check if the saved state has correctly been saved as "PENDING"
4. POST to the workflows API with an "APPROVE" event
5. GET the workflow using the workflowId and check if the saved state has correctly been saved as "APPROVED"

I have a hacky temporary solution to get around this in my project, but I was wondering if there was any recommended way to fix this, if this is something that can be fixed in the example, or if this is something that can be fixed in XState. The only solution that comes to mind on the XState side is a mechanism to subscribe to emitted snapshots synchronously where the next() calls are awaited (like a syncSubscribe or something? 🤔 ). This sounds like it might go against the Actor model or XState's design, so I'm curious what y'all have to say 🙂.

[davidkpiano]

Thanks for the report! From initial glance, it seems like the best way to fix this is to use a task queue.

Whenever you get a new snapshot, add it to the task queue and process saving the snapshots one at a time.

[azasorin-rss]

Thanks for the quick response! Makes sense, feels obvious in hindsight. 🤦

[davidkpiano]

I'm glad you pointed it out; it's something that I should add to the example.