The video has multiple sections, the first section is the one about XState. The custom observability tooling built by the Salty team included a nifty visualization of execution paths (3D too!)

I'm still a bit puzzled about where the conceptual boundaries of the "domain" state machine vs the "resilient process" state machine should be. I guess it becomes somewhat blurry.

I’ve not used a durable function execution system*. *list of some systems: • http://Temporal.io (fork of Uber’s https://cadenceworkflow.io) • Microsoft Azure Durable Functions • https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-overview/ (new/alpha, Dapr is also a Microsoft-backed project) “Durable” contrasts these with other systems like https://conductor.netflix.com, AWS Step Functions and SWF, https://cloud.google.com/workflows

Given the durable property, my understanding so far is that the resiliency comes from the integration into the durable execution framework. In Salty’s project, they briefly show the integration points between XState and Temporal. Temporal’s “activities” look to activate an XState state machine to run, and another part of Temporal stores the state machine’s state when the execution is paused/frozen while awaiting the next trigger/activity to wake it up.

I agree it’s blurry! And this style of system is simultaneously not new but also not widely used. My attempt to better understand the fuzzy boundaries –roughly mapping Salty’s work to https://github.com/fulcrologic/statecharts (see docs https://fulcrologic.github.io/statecharts): • The EventQueue and event loop loosely map to Temporal’s activities – the thing that “wakes-up” a state machine to make it run again (or run for the first time) • As far as resumption of a running state machine, the statecharts docs speak about the ability to serialize and store the “https://fulcrologic.github.io/statecharts/#_working_memory_and_identity” via a WorkingMemoryStore • etc (this is as far as I got 🙂 )

For more prior art and formalisms around durable workflow execution, see also Microsoft Research’s Orleans “virtual actors” which IIUC inspired a lot of these systems https://www.microsoft.com/en-us/research/project/orleans-virtual-actors

So iterating on the boundary question: in 8:17 they explain that some nodes in the xstate flow correspond to external calls, for which they use a temporal Activity. I guess this prevents you from having to model the "technical" state machine of the external call (with its success / failure / timeout events) as a child of the main statechart. So the boundary is AFAICT really on the business vs. technical domains: xstate models the business state and temporal hides all the technical state resulting from system interop.

That matches my understanding