Skip to content

Commit 199ef03

Browse files
committed
Skip PRRL renewal on UNASSIGNED_SEQ_NO
Today when renewing PRRLs we assert that any invalid "backwards" renewals must be because we are recovering the shard. In fact it's also possible to have `checkpointState.globalCheckpoint == SequenceNumbers.UNASSIGNED_SEQ_NO` on a tracked shard copy if the primary was just promoted and hasn't received checkpoints from all of its peers too. This commit weakens the assertion to match. Caught by a [failure of the full cluster restart tests](https://scans.gradle.com/s/5lllzgqtuegty/console-log#L8605) Relates elastic#41536
1 parent 76ff6e8 commit 199ef03

File tree

1 file changed

+3
-4
lines changed

1 file changed

+3
-4
lines changed

server/src/main/java/org/elasticsearch/index/seqno/ReplicationTracker.java

+3-4
Original file line numberDiff line numberDiff line change
@@ -508,10 +508,9 @@ public synchronized void renewPeerRecoveryRetentionLeases() {
508508
PEER_RECOVERY_RETENTION_LEASE_SOURCE);
509509
} else {
510510
// the retention lease is tied to the node, not the shard copy, so it's possible a copy was removed and now
511-
// we are in the process of recovering it again. The recovery process will fix the lease before initiating
512-
// tracking on this copy:
513-
assert checkpointState.tracked == false
514-
&& checkpointState.globalCheckpoint == SequenceNumbers.UNASSIGNED_SEQ_NO :
511+
// we are in the process of recovering it again, or maybe we were just promoted and have not yet received the
512+
// global checkpoints from our peers.
513+
assert checkpointState.globalCheckpoint == SequenceNumbers.UNASSIGNED_SEQ_NO :
515514
"cannot renew " + retentionLease + " according to " + checkpointState + " for " + shardRouting;
516515
}
517516
}

0 commit comments

Comments
 (0)