As a Developer, I need statemachine architecture suitable for development, so I can easily understand and modify the node's implementation

[akoptelov]

Definition of DONE:

• Rust library updated with more utilities for statemachine programming
• Semi-formal rules for statemachine elements (actions, state, etc)
• Automated checks for these rules ^

Currently there are lots of complaints about the way statemachine is implemented currently (should be sorted by severity, then subitem created for each item):

• [ ] Enabling condition semantics should be more strict
• [x] ~Actions can be referenced differently (action type/enclosing enum variant) that makes navigation difficult~ Now leaf actions are implemented by enum variants with named fields.
• [ ] #321
• [x] #253
• [ ] State initialization actions
• [x] #320
• [ ] Reducers/effects should return Result, so it would be hard to miss the case when enabling condition passes but the state update/effect does not happen because of incorrect code. As an example,
• [ ] State type guidelines should be developed, to make it more clear with respect of possible states and transitions between them (even without actions available)
• [ ] (?) Having both EnablingCondition and Into<Action> impls for an action looks redundant, as Action itself implements .
• [ ] Use consistent way of having action metadata for enabling conditions (missing now), reducers (wrapped in ActionWithMeta) and effects (as a separate parameter).

Here is the document about new/experimental statemachine implementation by @dkuehr: https://github.com/openmina/state_machine_exp/blob/main/node/README.md

And Here is a doc from @tizoc with comparison and analysis of the current and experimental approaches that is extremely relevant: https://gist.github.com/tizoc/c359f77769b61147060aa1ba31aeca49

[tizoc]

Enabling condition semantics should be more strict

@akoptelov can you expand on this? My issue with enabling conditions is different, I just don't find think that the current approach of having effect handlers dispatching all potentially useful actions that then get filtered by enabling conditions a good idea (to me, they make the code much harder to follow and reason about)

[akoptelov]

can you expand on this?

Well, this is mostly what I meant. If we have a violated enabling condition in runtime, this means program error that should be reported and fixed eventually. For testing/fuzzing this might be different though.

[binier]

If we have a violated enabling condition in runtime, this means program error that should be reported and fixed eventually. For testing/fuzzing this might be different though.

@akoptelov We could add dispatch_opt for optional dispatch (to use enabling condition for filtering). Otherwise by default dispatch would cause error log, or whatever the new error handler passed to the redux::Store does. Any thoughts?

[akoptelov]

@akoptelov We could add dispatch_opt for optional dispatch (to use enabling condition for filtering). Otherwise by default dispatch would cause error log, or whatever the new error handler passed to the redux::Store does. Any thoughts?

Yes, that might be an option. But I think this should be done case-by-case: sometimes we should be more explicit about effects.

E.g. for long-short forks, would it be better to have that dispatch_opt() || dispatch() expression, or explicit if is_short_range() ...?

But yeah, this solution firstly makes it obvious that the action might not be dispatched, and otherwise logs an error (and possibly panic in debug).

[tizoc]

E.g. for long-short forks, would it be better to have that dispatch_opt() || dispatch() expression, or explicit if is_short_range() ...?

Personally, for situations where concurrency is not much of an issue and clear flow is more important (case in point, the transition frontier) I would very much rather have the later.

[tizoc]

This is preliminar and not complete, but here is @dkuehr's doc on his implementation: https://gist.github.com/dkuehr/6a0292036becdddd3a5853a18ebf08c2

[akoptelov]

This is preliminar and not complete, but here is @dkuehr's doc on his implementation: https://gist.github.com/dkuehr/6a0292036becdddd3a5853a18ebf08c2

Added that to the top comment as well.