State machine design

[da-kami]

State machine ideas

In the past we have iterated over state machines in rust code several times.
For the CFD in the product we have a state machine again.

There is a lot of possible ways to implement state representation and transitioning. It would be nice if we could come up with some rules and document them in our architecture guidelines so we can keep them in mind when extending the program.
This is not especially important for the MVP, but more an overall learning and evolution :)

Here are some of my thoughts.

At the moment there is no possible transitions defined in our cfd state machine. We are just freely transitioning into the next state according to state (as in program state) changes in the program flow.
I think the state transitions should be defined more restrictive, and only the possible transitions should be allowed.
This leads to some questions.

How should transitions be driven?

1. Tell an actor to "transition" and the actor decides if it is possible?
2. Let the outside tell the actor what state is wanted?
3. Let the actor just transition to the next possible state (without knowledge what the outside wants)?
4. Where should the state transition logic live in the code?

• In the state enum itself as a function that just indicates what state transitions are "sane"?
• in one big function that represents the state machine (xmr-btc model)?

5. How far do we want to drive this?

I think the "one big state machine" approach we took in xmr-btc was somewhat restrictive.

How should the states be designed?

The states represent "saving points" for me. I.e. when transitioning to a new state we want to record that in the database.

• Granularity?
  • Should we have nested states? If so, should all the nested states be regarded as saving points as well?

[thomaseizinger]

Thank you for writing this up Daniel!

I think your best bet will be to model the cfd and its states separately from actors and expose functions that perform state transitions.

Note that, because we need to represent all possible states at once (through an enum), these transition functions will have to be defined on the enum itself and thus from a type-system perspective, you will always be able to call any of them.

The transition functions itself will then have to be fallible because you could be in a state that doesn't allow the transition.

Actors would call these transition functions upon receiving messages.

[da-kami]

This was basically resolved by introducing the actor model. Thanks @thomaseizinger - unpinning this for now, feel free to delete it.