Repository navigation
perf: cut governance and epoch interval waits on Leios - #3740
Merged
Merged
Conversation
The guardrails proposals are never voted on, and the committee and DReps are locked, so no pparam update can be enacted and change the previous action ID used in a proposal. Crossing an epoch boundary between building and submitting a proposal is therefore harmless. Waiting for the epoch interval cost a new block before each of ~120 proposals, plus waiting out the end of epoch whenever a proposal fell into it. On the Leios testnet (20 s blocks, 240 s end of epoch buffer in 800 s epochs) that was ~75 of the test's 140 minutes.
`wait_for_epoch_interval` waited for a new block before every check, only to get an up-to-date slot number from the tip. On the Leios testnet, with a block every 20 s on average, that cost ~20 s per call, and the function is used in ~90 places. Derive the current slot from wall clock (`query slot-number`) instead. Fall back to the tip if the query fails, e.g. past the forecast horizon. With `check_slot`, the slot of the last forged block must match the interval, so the tip is still used there. Callers often query the current epoch right after the wait. As the first block of an epoch can come a while after the epoch started, wait until the tip is in the current epoch, and only then check that the time is in the interval, as the block can come late in the epoch.
mkoura
requested
a balanced review from Copilot
and removed request for
saratomaz
October 6, 2026 10:59
Contributor
There was a problem hiding this comment.
Copilot review overview
🔵 Needs a closer look
The timing helper has broad E2E impact and relies on race-sensitive node and wall-clock behavior.
Review effort: Balanced
Findings: None
What changed in this PR
Optimizes Leios test execution by avoiding unnecessary block and epoch waits.
Changes:
- Uses wall-clock slot queries with tip fallback.
- Adds simulated-chain unit coverage.
- Removes redundant guardrail proposal waits.
| File | Description |
|---|---|
framework_tests/test_clusterlib_utils.py |
Tests interval-wait scenarios. |
cardano_node_tests/utils/clusterlib_utils.py |
Implements wall-clock timing. |
cardano_node_tests/tests/tests_conway/test_guardrails.py |
Removes proposal wait. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
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.
On the Leios testnet (
leios_fast: 800 s epochs, a block every 20 s on average), a lot of test time goes to waiting for blocks and epoch windows that don't need to be waited for.Guardrails: don't wait for epoch interval
test_guardrailswaited for the epoch interval before each of its ~120 pparam proposals. That meant waiting for a new block every time, and also waiting out the last 240 s of each epoch whenever a proposal fell into it. The proposals are never voted on, and the committee and DReps are locked, so nothing can be enacted to change the previous action ID used in a proposal. Crossing an epoch boundary is harmless.In the last Leios run this was ~75 of the test's 140 minutes (35 min of end-of-epoch waits, ~40 min of per-proposal block waits).
wait_for_epoch_interval: use wall clockwait_for_epoch_intervalwaited for a new block before measuring the time, only to get an up-to-date slot number from the tip. On Leios that is ~20 s per call, and the function is used in ~90 places.cardano-cli query slot-number).check_slot, the slot of the last forged block must be in the interval, so the tip is still used there.stop, it moves on to the next epoch as before.Testing
framework_tests/test_clusterlib_utils.py, using a simulated chain clock: in-interval without a block wait, sleep until start, tip still in the previous epoch, first block of the epoch afterstop, past the interval,force_epoch,check_slot, the slot query failing at the start or mid-wait, and the tip never reaching the epoch.test_stake_snapshot,test_delegate_using_pool_id,test_update_stake_pool_metadata,test_pool_blocks.