Consider proposing a write and this code path:

Let's say the maxLeaseIndex assigned here is 100 and the timestamp of the command is 1000. The closed timestamp tracker now knows 100 as the MLAI of a command that has an effect at ts=1000.

The proposal now hits this code path

and gets reproposed with a new lease index, let's say 200:

From the perspective of closed timestamps, this is problematic. A CT update might have been sent out stating that "if you've caught up to lease index 100, you've seen all the proposals that will have an effect on timestamp 1000". But it turns out that in this example, such a command will pop out of raft at lease index 200.

It seems that this can cause a violation of the invariant that any closed out MVCC snapshot is immutable.

As for fixing this, the "natural" attempt is to go through the tracker again. However, if we find that the tracker pushes the proposal (i.e. the original timestamp has closed out, as it has in this example), we need someone to reevaluate it.

It's possible that we would be better off removing this one-off below-raft-reproposal path completely and instead opting for having the client reevaluate the command unconditionally. The one-off path was originally introduced to accommodate pipelined writes (where the client returns early and isn't around to reevaluate the command) but this doesn't mean we can't reevaluate the batch, just that we have to create a goroutine to do so. This approach is less performant, but this is a rare case where simplicity is more important than performance.