One would expect propBuf.liBase to be initialized on a new leaseholder when the lease changes hands. However, it doesn't appear to be. We seem to only synchronize the propBuf's tracking with the replica state through this call, happening at the end of the first Flush():
https://github.com/cockroachdb/cockroach/blob/3b7dff158a796e03c83898f19ac512e519c3d128/pkg/kv/kvserver/replica_proposal_buf.go#L474
When a lease changes hands, I think we need to set the liBase, and also to reset the buffer's counter (which gets added on top of the liBase), one way or another. And one way to do it is to force a Flush() immediately once the new lease applies.
@nvanbenschoten said that he discovered the same thing a while back, and looked briefly into whether this problem results in the first batch of commands proposed after a lease change being rejected, and for some reason didn't see it happen. So maybe there's some hidden saving grace somewhere.
Jira issue: CRDB-3169
One would expect
propBuf.liBaseto be initialized on a new leaseholder when the lease changes hands. However, it doesn't appear to be. We seem to only synchronize thepropBuf'stracking with the replica state through this call, happening at the end of the firstFlush():https://github.com/cockroachdb/cockroach/blob/3b7dff158a796e03c83898f19ac512e519c3d128/pkg/kv/kvserver/replica_proposal_buf.go#L474
When a lease changes hands, I think we need to set the
liBase, and also to reset the buffer's counter (which gets added on top of theliBase), one way or another. And one way to do it is to force aFlush()immediately once the new lease applies.@nvanbenschoten said that he discovered the same thing a while back, and looked briefly into whether this problem results in the first batch of commands proposed after a lease change being rejected, and for some reason didn't see it happen. So maybe there's some hidden saving grace somewhere.
Jira issue: CRDB-3169