Make state machine commands extensible?

[dumbbell]

As part of an experiment with new snapshot strategies, I'm looking at adding some data to all existing commands.

I could abuse the map available in some commands; for instance the options map in a #put{}:

-record(put, {path :: khepri_path:native_pattern(),
              payload = ?NO_PAYLOAD :: khepri_payload:payload(),
              options = #{} :: khepri:tree_options() | khepri:put_options()}).

But other commands have no such map; for instance, #tx{}:

-record(tx, {'fun' :: horus:horus_fun() | khepri_path:pattern(),
             args = [] :: list()}).

An option would be to wrap a command inside another command, like we did for #dedup{}:

-record(dedup, {ref :: reference(),
                expiry :: integer(),
                command :: khepri_machine:command()}).

But we would end up with a chain of commands, which might be a good or a bad thing.

I was wondering how to make commands extensible and more future-proof. I came up with a redesign of existing commands so that they would have the following form:

%% A set of properties common to all commands.
-record(common_ext_v1, {ref :: reference(),
                        expiry :: integer(),
                        cmd_size = 0 :: non_neg_integer()}).

%% A set of properties specific to `#put_v*{}'.
-record(put_ext_v1, {common :: #common_ext_v1{},
                     tree_options = #{} :: khepri:tree_options(),
                     put_options = #{} :: khepri:put_options()}).

%% The replacement of `#put{}'.
-record(put_v2, {path :: khepri_path:native_pattern(),
                 payload = ?NO_PAYLOAD :: khepri_payload:payload(),
                 ext = #put_ext_v1{}}).

%% Likewise for `#delete{}' and so on.
-record(delete_ext_v1, {common :: #common_ext_v1{},
                        tree_options = #{} :: khepri:tree_options()}).
-record(delete_v2, {path :: khepri_path:native_pattern(),
                    ext = #delete_ext_v1{}}).

Therefore, we would have a #put_v2{} command having a version in the name to differentiate it from the original #put{} and from a possible future #put_v3{}. I believe this record would rarely change.

Then, the last field of that record would receive the extension to the base command record. For #put_v2{}, this would be #put_ext_v1{}. This extension record is specific to the put command and is also versioned.

Finally, because we would have properties common to all commands (like the command size I would like to add that triggered all this), we could have a #common_ext_v1{} record in the first field of the command-specific extension record.

Now that I think of it, separating the common and command-specific extensions could be more practicle because a new common extension would warrant a new version of the command-specific extension from a type spec point of view. So perhaps, it would be best to have:

-record(put_v2, {path :: khepri_path:native_pattern(),
                 payload = ?NO_PAYLOAD :: khepri_payload:payload(),
                 ext = #put_ext_v1{} :: #put_ext_v1{},
                 ext_common = #common_ext_v1{} :: #common_ext_v1{}}).

And now that I wrote it, it would warrant a #put_v2{} command if I follow this reasoning :-)

Anyway, what do you think of this approach? @the-mikedavis? How does it compare to wrapping a command inside another command to add properties to the inner command?