eth/eventhandler: deflake slashing-protection stamp assertions - #2969
eth/eventhandler: deflake slashing-protection stamp assertions#2969momosh-ssv wants to merge 1 commit into
Conversation
TestHandleBlockEventsStream asserted the stored highest attestation epochs and highest proposal slot against EstimatedCurrentSlot() re-evaluated at assertion time. The stamp is written during event processing (BumpSlashingProtectionTxn reads the clock then), so any slot boundary crossing between stamp and assertion fails the equality spuriously - seen on CI as expected 100 / actual 101 in the ClusterLiquidated subtest (e.g. run 29833681337). Capture the wall-clock slot window around the event processing that writes the stamp and assert the stored values fall inside it. The ClusterReactivated subtest had the same race; the third reactivation subtest's Greater-than assertions span a ~900-slot jump and are left as is.
Codecov Report✅ All modified and coverable lines are covered by tests. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Greptile SummaryUpdates slashing-protection test assertions to use slot windows captured around event processing, preserving source/target epoch relationships while avoiding wall-clock boundary flakes. Confidence Score: 5/5The PR appears safe to merge with no actionable defects identified. The captured intervals enclose the relevant slashing-protection writes, use the same beacon clock as production stamping, and preserve the expected attestation and proposal invariants.
|
| Filename | Overview |
|---|---|
| eth/eventhandler/event_handler_test.go | Captures the slot range surrounding each relevant stamp operation and validates attestation and proposal values against that range. |
Reviews (1): Last reviewed commit: "eth/eventhandler: deflake slashing-prote..." | Re-trigger Greptile
TestHandleBlockEventsStreamasserted the stored highest-attestation epochs and highest-proposal slot againstEstimatedCurrentSlot()re-evaluated at assertion time. The stamp itself is written during event processing (BumpSlashingProtectionTxnreads the clock then), so a slot boundary crossing between stamp and assertion fails the equality spuriously — seen on CI asexpected: 0x64 / actual: 0x65in theClusterLiquidatedsubtest (run); the whole test takes ~25s on CI, so with 12s slots a crossing is routine.Fix: capture the wall-clock slot window around the event processing that writes the stamp, and assert the stored values fall inside
[from, to](withsource == target − 1preserved). Applied to both racy subtests (ClusterLiquidated, whose stamp happens back in the secondValidatorAddedsubtest, andClusterReactivated). The third reactivation subtest'sGreater-than assertions span a deliberate ~900-slot genesis jump and are race-safe, so they're untouched.Test-only; no production code changed. Part of a broader CI-flake cleanup (issue to follow).