From 36c91072f0d85c539dcffcf6846a3d19d266daa8 Mon Sep 17 00:00:00 2001 From: Johnathan Corgan Date: Sat, 15 Aug 2026 13:53:33 +0000 Subject: [PATCH] Describe the rekey expiry test in terms a reader outside the project can check The comment explained the condition by reference to a review round rather than to the code, which means nothing to anyone reading the test on its own. --- src/proto/fsp/tests/core.rs | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/proto/fsp/tests/core.rs b/src/proto/fsp/tests/core.rs index 31619bec..f23d8ea7 100644 --- a/src/proto/fsp/tests/core.rs +++ b/src/proto/fsp/tests/core.rs @@ -281,10 +281,10 @@ fn poll_rekey_expiry_reads_the_handshake_flag_and_never_the_pending_flag() { let fsp = Fsp::new(); // A completed rekey waiting for its cutover, with an expired peer stamp // and no handshake beside it. `has_pending` must not stand in for - // `rekey_in_progress` here: widening the condition to either flag is the - // shape the third correction reversed, and it discards the epoch the peer - // has already moved to. The other two arms of this snapshot are quiet, so - // an empty result can only mean the abandon arm declined. + // `rekey_in_progress` here: widening the condition to either flag would + // discard the epoch the peer has already moved to. The other two arms of + // this snapshot are quiet, so an empty result can only mean the abandon + // arm declined. let mut s = session_snapshot(11); s.has_pending = true; s.rekey_in_progress = false;