TOSQUASH some TODOs about the GSM leaving CaughtUp

Author: nfrisby

ouroboros-consensus/src/unstable-consensus-testlib/Test/CsjModel.hs

@@ -48,11 +48,19 @@ import           Test.CsjModel.StateTypes
 -------------------------------------------------------------------------------}
 
 -- | Events the CSJ logic needs to react to
+--
+-- TODO copy <https://github.com/IntersectMBO/ouroboros-consensus/pull/1492>'s
+-- explanation that a @Reengage@ stimulus is unnecessary even when the GSM
+-- transitions out of 'Ouroboros.Consensus.Node.GsmState.CaughtUp'
 data CsjStimulus p a =
     -- | The peer responded to a ChainSync message
     ChainSyncReply !(ChainSyncReply p a)
   |
-    -- | The peer just connected
+    -- | An upstream peer just connected
+    --
+    -- Note that this should simply not be called when the Genesis State
+    -- Machine (GSM) is in the 'Ouroboros.Consensus.Node.GsmState.CaughtUp'
+    -- state.
     --
     -- The argument is the payload for the current immutable tip.
     Connect !a
@@ -1164,6 +1172,11 @@ newJumpRequest2 y = \jump ->
 -- Discards however much of the new 'JumpRequest' the Jumper has already
 -- rejected via 'anticomm' and then builds the final 'Bisecting' if any jump
 -- points remain.
+--
+-- TODO how much more complicated would this logic be if the invariant for
+-- Jumpers were merely @'candidate' extends 'comm'@ rather than @'candidate' ==
+-- 'comm'@? Letting candidates exceed commitments seems like it could reduce
+-- the cost of the GSM transition from CaughtUp to (Pre)Syncing.
 newJumpRequest3 ::
      Ord p
   => Set p