[Brain Dump] Event-As-Destination-State

[Kelerchian]

In a swarm protocol:

• Transition map one-to-one to a guard event
• Transition map one-to-one to a combination of role, source state, and target state
• There does not seem to be a need for ordered-multi-events transition.

With those properties (and hopefully no need for another compiliation step) swarm protocol and role protocol can be defined this way:

const swarmProtocol = Swarm.createProtocol()
  .state(["A", "B", "C1", "C2", "D"])
  .role("taxi", "passenger")
  .transition("passenger", "A", "B").withPayload<ABPayload>() // creates event type "passenger-A-to-B"
  .transition("taxi", "B", "B").withPayload<ABPayload>() // creates event type "taxi-B-to-B" (Loop)
  .transition("taxi", "B", "C1").withPayload<BC1Payload>() // creates event type "taxi-B-to-C1"
  .transition("passenger", "B", "C2").withPayload<BC2Payload>() // creates event type "passenger-B-to-C2"
  .transition("passenger", "C1", "D").withPayload<C1DPayload>() // creates event type "passenger-B-to-C2" 
  .transition("taxi", "C2", "D").withPayload<C2DPayload>() // creates event type "taxi-B-to-C2"
  .transition("passenger", "C2", "D", (ctx, payload) => ctx.additionalTag(`sometag:${payload.numprop}`)).withPayload<C2DPayload>() // creates event type "passenger-B-to-C2"
  .finish() // builds the swarm protocol complete with the graph 
  
// payload-less machine-runner
// only give payload-less states, but leave commands intact
const machineRunner = createMachineRunner(actyx, tags, swarmProtocol.buildMachineFor("passenger"));

// in default machine
state.commands?.["A-to-B"](theEventPayload);

// custom machines uses old syntax
const taxiMachineProtocol = swarmProtocol.buildMachineCustomRole("taxi");

const A = taxiMachineProtocol 
  .designState("A")
  .withPayload<SomePayload>()
  .commands("A-to-B", (ctx, value) => [{ ...payloadOfAToB, value }])
  .finish()

const B = taxiMachineProtocol 
  .designState("B")
  .withPayload<SomePayload>()
  .finish()
  
// custom machines need to be run with `checkProjection`

checkProjection(swarmProtocol, taxiMachineProtocol)

[rkuhn]

Yes, something similar occurred to me some months ago: we could keep all state payload processing out of the machine description if we give the information to the consumer of the current state. I think this means including all previous event payloads, not only the latest one; or it means adding an event selection language to say “I want the very first event, all bidding events, and the last assigned event”. The latter can also be done by complementing the current state object with an event accessor that offers such an API.

[rkuhn]

This would also make it trivial to keep snapshots of old states around, limiting the effort of timetravel replays.

[Kelerchian]

we could keep all state payload processing out of the machine description if we give the information to the consumer of the current state

It did not occur to me. My initial intuition is that this sounds like a good idea.
Although I can't imagine the full impact nor how the API should feel like and how it would differ from what we have right now.

I want the very first event, all bidding events, and the last assigned event

One thing I always feel a bit off about this is that we often treat (and suggest people, or almost encourage even) a swarm protocol as a linear process whereas it might be non-linear, and some events might be ignored due to a loop (in the graph). I just feel that this might be one of the future pitfalls that we can't yet identify because of the lack of data.

Not a crucial point as of right now though.

[rkuhn]

Regarding linearity: our current swarm protocols permit linear sequences, choices (i.e. branches), and cycles. They currently do not permit any form of parallelism, though, which means that the resulting event log always is linear in nature. Events from invalid branches are ignored.

So with this theory, I think it makes sense to view the current state and the history of getting there as a linear sequence of events.

---

In the future, we may extend the theory to explicitly model (and regulate) parallelism. At that point the history of a state after joining two parallel parts of the workflow is more complex; it would take more thought to figure out how to present this to the programmer. But since we don’t have such a theory yet, it would be premature to take guesses about its constraints.

[Kelerchian]

At that point the history of a state after joining two parallel parts of the workflow is more complex; it would take more thought to figure out how to present this to the programmer. But since we don’t have such a theory yet, it would be premature to take guesses about its constraints.

Something similar to multi-events reactions, but unordered, unique, and has a triggering/opening-event (but not a closing one as the closing can be indicated by having the multi-events criteria fulfilled)?

[rkuhn]

As I said: there’s no point trying to figure this out yet because the underlying theory doesn’t yet exist.

[Kelerchian]

I see, shelving this for now