mirror of
https://github.com/scylladb/scylladb.git
synced 2026-05-12 19:02:12 +00:00
97ff98f3a7
The call to `raft::server::add_entry` in `announce_with_raft` may fail e.g. due to a leader change happening when we try to commit the entry. In cases like this it makes sense to retry the command so we don't prematurely report an error to the client. This may result in double application of the command. Fortunately, the schema change command is idempotent thanks to the group 0 state ID mechanism (originally used to prevent conflicting concurrent changes from happening). Indeed, once a command passes the state ID check, it changes the group 0 history last state ID, causing all later applications of that same command to fail the check. Similarly, once a command fails the state ID check, it means that the last state ID is different than the one observed when the command was being constructed, so all further applications of the command will also fail the check (it is not possible for the last state ID to change from X to Y then back to X). Note that this reasoning only works for commands with `prev_state_id` engaged, such as the ones which we're using in `migration_manager::announce_with_raft`. It would not work with "unconditional commands" where `prev_state_id` is `nullopt` - for those commands no state ID check is performed. It could still be safe to retry those commands if they are idempotent for a different reason. (Note: actually, our schema commands are already idempotent even without the state ID check, because they simply apply a set of mutations, and applying the same mutations twice is the same as applying them once.) Message-Id: <20220131152926.18087-1-kbraun@scylladb.com>