cardano-testnet: fail fast with a diagnosis when the chain stalls irrecoverably#6616
Open
palas wants to merge 1 commit into
Open
cardano-testnet: fail fast with a diagnosis when the chain stalls irrecoverably#6616palas wants to merge 1 commit into
palas wants to merge 1 commit into
Conversation
…ecoverably A `cardano-testnet` network permanently stops producing blocks whenever no block is forged for longer than the ledger view forecast horizon of `3 * securityParam / activeSlotsCoeff` slots - `300 slots = 30s` of wall clock with the default genesis options (`securityParam=5`, `activeSlotsCoeff=0.05`, `slotLength=0.1s`). Past that point every node fails its leadership check with `Forge.Loop.NoLedgerView` and the chain can never extend again. This happens when node startup exceeds the start-time offset (`startTimeOffsetSeconds`, `15s`) plus the horizon, or when an overloaded machine starves the nodes of CPU for longer than the horizon mid-run, and it made tests hang forever in chain-progress waits (`waitForEpochs`/`waitForBlocks`/`waitUntilEpoch`) whose deadlines are measured in epochs/blocks/slots that never arrive. Detect the situation instead, as early as it is provable, and explain it: * `chainForecastHorizon` computes the horizon from the `ShelleyGenesis` backing the testnet (read via the node configuration); the stall threshold is `max 60s (2 * horizon)` - `60s` with the default genesis - falling back to a conservative `300s` when the genesis cannot be read. * `retryUntilRightM`: when no chain-state update arrives for the whole stall threshold (previously a silently swallowed `300s` fallback), fail with a message explaining the mechanism, the actual horizon, and pointing at the node logs. * `waitUntilEpoch`: `race` `foldEpochState` against a stall watchdog with the same semantics and diagnostic. * `waitForBlockThrow`: the startup deadline is now derived from the genesis (`startTimeOffsetSeconds + horizon + 15s` margin instead of a flat `45s`) and the error explains the likely cause and remedy. Attempts to fix #5762 (the hangs)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Another attempt at reducing/avoiding the flakiness of tests by stopping the waits when the chain is dead.
Description
A
cardano-testnetnetwork permanently stops producing blocks whenever no block is forged for longer than the ledger view forecast horizon of3 * securityParam / activeSlotsCoeffslots -300 slots = 30sof wall clock with the default genesis options (securityParam=5,activeSlotsCoeff=0.05,slotLength=0.1s). Past that point every node fails its leadership check withForge.Loop.NoLedgerViewand the chain can never extend again. This happens when node startup exceeds the start-time offset (startTimeOffsetSeconds,15s) plus the horizon, or when an overloaded machine starves the nodes of CPU for longer than the horizon mid-run, and it made tests hang forever in chain-progress waits (waitForEpochs/waitForBlocks/waitUntilEpoch) whose deadlines are measured in epochs/blocks/slots that never arrive.Detect the situation instead, as early as it is provable, and explain it:
chainForecastHorizoncomputes the horizon from theShelleyGenesisbacking the testnet (read via the node configuration); the stall threshold ismax 60s (2 * horizon)-60swith the default genesis - falling back to a conservative300swhen the genesis cannot be read.retryUntilRightM: when no chain-state update arrives for the whole stall threshold (previously a silently swallowed300sfallback), fail with a message explaining the mechanism, the actual horizon, and pointing at the node logs.waitUntilEpoch:racefoldEpochStateagainst a stall watchdog with the same semantics and diagnostic.waitForBlockThrow: the startup deadline is now derived from the genesis (startTimeOffsetSeconds + horizon + 15smargin instead of a flat45s) and the error explains the likely cause and remedy.Attempts to fix #5762 (the hangs)
Checklist
See Running tests for more details
CHANGELOG.mdfor affected package.cabalfiles are updatedhlint. See.github/workflows/check-hlint.ymlto get thehlintversionstylish-haskell. See.github/workflows/stylish-haskell.ymlto get thestylish-haskellversionghc-9.6andghc-9.12