Codecov Report

❌ Patch coverage is 83.12830% with 96 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.31%. Comparing base (be0c997) to head (4342353).

@@             Coverage Diff              @@
##             master    #3425      +/-   ##
============================================
+ Coverage     74.29%   74.31%   +0.02%     
  Complexity      943      943              
============================================
  Files          1245     1247       +2     
  Lines        121687   122232     +545     
  Branches      97959    98530     +571     
============================================
+ Hits          90403    90841     +438     
- Misses        28328    28389      +61     
- Partials       2956     3002      +46     

/ready

Ok, the idea is sound and looks good, there is one piece that I think is worth mentioning, replica_id generation.

Currently we are supplying the replica_id through an CLI argument, it's fine for an "seed" cluster values (e.g perfect information first bootstrap), but falls flat in cases where we would like to have dynamic cluster counts.

One way to address this isssue would be to keep the initial seed, but on the first bootstrap (when the metadata log is empty, so the cluster is fresh), write that seed configuration into the metadata log with op=0. Make the replica_id be generated at runtime, rather than supplied (the one comming from CLI arg would be used as an index into the replicas set, so the initial seed configuration has granular control over all of the nodes required for determinism).
After the initial configuration is written to the log and resolved, we can go through the challenge protocol with those nodes). I omitted one important detail which is ReplicaJoin command, as this is the command that will assign the replica_id (it has to be written to the log and replicated).