I was playing with https://raft.github.io/ with this situation, but have a big doubt about what is going on.
After a leader is elected, I make a request to it.
The leader send the append entry with the new entry.
The leader crash.
At this point in the visualization I see the cluster electing a new leader
The new leader and all the other nodes have the last entry sent by the leader in the previous term, but it stays uncommitted until a new request is issued in the state machine
Does it imply that if no more writes are going to happen in the cluster the uncommitted changes will never be committed any nodes, hence they will be “invisible” if I try to read the state of the cluster?
(this last part I have doubts if I’m confusing different things talking about read the cluster state from a client)
Yes, leader can only commit starting for first log/event of the elected term. To avoid such scenario you can add a no-op log/event that does not have any effect on state machine. Now leader can commit no-op log and all the log until no-op logs are considered committed, and follower will apply all the remaining logs.
All the logs/events applied on state machine must be deterministic. So if state machine depends time(uses system clock), then time should be also added (and replicated) log/event. In this case time log/event can be also used