run e2e sync test until epoch 185 (was reduced from 182 to 176 due to regression)#749
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughStandardises CI workflow string defaults and bumps preprod epoch; ignores Changes
Sequence Diagram(s)sequenceDiagram
rect rgba(200,200,255,0.5)
participant Upstream as Upstream
participant TrackPeers as TrackPeers
participant Effects as Effects/Store
participant Defer as DeferReqNext
participant Initiator as InitiatorHandler
end
Upstream->>TrackPeers: roll_forward(header)
TrackPeers->>Effects: ledger_applied_block_height(eff)
Effects->>Effects: read best_chain_hash → load header
TrackPeers->>Defer: Register { handler, min_ledger_height }
Note right of Defer: schedule_after(Poll, poll_ms)
Defer->>Initiator: RequestNext when ledger height >= min_h
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
crates/amaru-consensus/src/stages/track_peers/mod.rs (1)
38-44: Heads up on a sneaky little clippy attribute, legend!The
#[expect(clippy::expect_used)]attribute on line 39 seems like a leftover from the old implementation – the current function usesunwrap_orwhich doesn't trigger that lint. It's like leaving the cheat codes enabled after you've already beaten the boss fair and square!Consider removing it to keep the code tidy:
🧹 Remove unnecessary attribute
/// Block height of the furthest ledger-applied state: volatile tip if present, otherwise stable tip. -#[expect(clippy::expect_used)] fn ledger_applied_block_height<T: SendData>(eff: &Effects<T>) -> BlockHeight { let store = Store::new(eff.clone()); let best = store.get_best_chain_hash(); store.load_header(&best).map(|h| h.block_height()).unwrap_or(BlockHeight::from(0)) }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@crates/amaru-consensus/src/stages/track_peers/mod.rs` around lines 38 - 44, The attribute #[expect(clippy::expect_used)] above the function ledger_applied_block_height is stale (the function uses unwrap_or, not expect); remove that attribute annotation so the codebase no longer contains an unnecessary clippy expectation. Locate the ledger_applied_block_height<T: SendData>(eff: &Effects<T>) -> BlockHeight function and delete the #[expect(clippy::expect_used)] line immediately preceding it.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@crates/amaru-consensus/src/stages/track_peers/mod.rs`:
- Around line 38-44: The attribute #[expect(clippy::expect_used)] above the
function ledger_applied_block_height is stale (the function uses unwrap_or, not
expect); remove that attribute annotation so the codebase no longer contains an
unnecessary clippy expectation. Locate the ledger_applied_block_height<T:
SendData>(eff: &Effects<T>) -> BlockHeight function and delete the
#[expect(clippy::expect_used)] line immediately preceding it.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 4f3eb964-8d4b-4f1c-bb9a-4ba74daaf33f
📒 Files selected for processing (8)
crates/amaru-consensus/src/stages/adopt_chain/mod.rscrates/amaru-consensus/src/stages/adopt_chain/test_setup.rscrates/amaru-consensus/src/stages/adopt_chain/tests.rscrates/amaru-consensus/src/stages/track_peers/defer_req_next.rscrates/amaru-consensus/src/stages/track_peers/mod.rscrates/amaru-consensus/src/stages/track_peers/test_setup.rscrates/amaru-consensus/src/stages/track_peers/tests.rscrates/amaru/src/stages/config.rs
✅ Files skipped from review due to trivial changes (1)
- crates/amaru/src/stages/config.rs
etorreborre
force-pushed
the
rk/preprod-sync
branch
2 times, most recently
from
2898d84 to
d07475a
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
crates/amaru-consensus/src/stages/adopt_chain/tests.rs (1)
115-133:⚠️ Potential issue | 🟠 MajorUpdate the expected state for the suppressed counter.
These tests now expect the DEBUG branch for
"adopted tip"; that branch incrementsstate.suppressedbefore returning, so the finalte_stateshould expectsuppressed = 1. Otherwise the trace assertion will be off by one — a sneaky little Elden Ring trap.🛠️ Proposed test fix
let mut expected = prep.state.clone(); expected.current_best_tip = msg; + expected.suppressed = 1; assert_trace( &running, &[Apply the same
expected.suppressed = 1;update in all three adopting tests.Also applies to: 159-187, 212-234
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@crates/amaru-consensus/src/stages/adopt_chain/tests.rs` around lines 115 - 133, The final expected state in the adopting-tip tests must account for the DEBUG branch incrementing state.suppressed; update the test setup to set expected.suppressed = 1 before asserting te_state so the trace matches the branch that increments suppressed, and apply the same change in all three adopting tests that build expected and assert te_state (refer to the local variable expected, the state.suppressed field, and the te_state assertions paired with the AdoptChainMsg::new inputs).crates/amaru-consensus/src/stages/track_peers/defer_req_next.rs (1)
27-48:⚠️ Potential issue | 🟡 MinorNice cleanup, but the
Cancelsafety-net's gone walkabout — pending entries may orphanDropping peer identity from
Register(and binningCancel) makes the message shape much tidier, Marie Kondo would approve. The thing tickling my brain though: intrack_peers/mod.rsa peer gets removed onvalidate_headerorstore_headererrors (lines 242-243 and 254-255) and on roll-back failures (lines 338-339). WithCancelgone, any still-pending(handler, min_h)tuple that was registered for that peer just sits instate.pendingforever, or at least untilledger_applied_block_heightdrifts pastmin_h— which, for a misbehaving peer we've already kicked, might be "quite a while" or, in the worst case, never (e.g. we're stuck on a dead branch with no further progress).The eventual
send(&handler, RequestNext)to a dead initiator StageRef is almost certainly a no-op on pure-stage, so it's not a correctness foot-bullet — more of a "pending vec grows monotonically with peer churn" smell. It's a trap! only if you care about long-running nodes with lots of flaky peers.Options if you don't want to bring
Cancelback:
- Have
dispatch_readyalso drop entries whosehandleris known-dead (if pure-stage exposes liveness).- Or document that the pending vec is allowed to accumulate tombstones and is pruned lazily when the ledger catches up.
Happy to leave as-is if the expected operational profile is "peer removals are rare and the ledger always advances eventually" — just flagging so it's a conscious call rather than a gotcha hiding in the long grass.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@crates/amaru-consensus/src/stages/track_peers/defer_req_next.rs` around lines 27 - 48, The pending vector can leak entries for peers that have been removed because Register no longer carries peer identity and there is no Cancel; to fix, either restore a Cancel variant on DeferReqNextMsg (e.g., Cancel { handler: StageRef<InitiatorMessage> } and remove matching tuples from DeferReqNext::pending in stage on Cancel) or add pruning logic where entries are dispatched (e.g., in dispatch_ready or the Poll handling in stage) to detect dead StageRef handlers and drop their (handler, min_ledger_height) tuples; refer to DeferReqNextMsg::{Register, Poll}, the DeferReqNext.pending field, and the stage(...) handler to implement the chosen approach.
🧹 Nitpick comments (1)
crates/amaru-consensus/src/stages/track_peers/test_setup.rs (1)
97-99: Tiny nit — stay consistent with the sibling stage, mate.G'day! Functionally
Box::new(GetBestChainHashEffect)is grand — it's a unit struct, so this and::new()compile down to the same thing. But over incrates/amaru-consensus/src/stages/select_chain/test_setup.rsthe same helper callsGetBestChainHashEffect::new()(see context snippet 2), andnew()exists specifically for this purpose (snippet 1). Like Neo picking the same pill twice, let's keep the twin helpers looking identical so future grep-archaeologists don't do a double-take.♻️ Proposed tweak
pub fn te_get_best_chain_hash(at_stage: &str) -> TraceEntry { - TraceEntry::suspend(Effect::external(at_stage, Box::new(GetBestChainHashEffect))) + TraceEntry::suspend(Effect::external(at_stage, Box::new(GetBestChainHashEffect::new()))) }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@crates/amaru-consensus/src/stages/track_peers/test_setup.rs` around lines 97 - 99, The helper te_get_best_chain_hash is inconsistent with its sibling: instead of constructing the unit effect with Box::new(GetBestChainHashEffect) use the existing constructor to match style; replace Box::new(GetBestChainHashEffect) with Box::new(GetBestChainHashEffect::new()) so TraceEntry::suspend(Effect::external(at_stage, Box::new(GetBestChainHashEffect::new()))) mirrors the select_chain test setup.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@crates/amaru-consensus/src/stages/track_peers/mod.rs`:
- Around line 39-44: The function ledger_applied_block_height currently reads
from the consensus chain store (Store::get_best_chain_hash → load_header) but is
misnamed and documented as returning the ledger-applied tip; rename the function
to best_chain_stored_block_height and update its docstring to state it returns
the best-chain tip stored in the consensus Store, and then update any callers
(e.g., the defer_req_next::dispatch_ready gate that compares ledger_height >=
min_h) to either use this renamed best_chain_stored_block_height when they
really mean the consensus store tip or, if they require the actual
ledger-applied tip, replace the Store lookup with the proper ledger-applied-tip
retrieval via Effects<T> (adapt the call to the ledger-applied API available on
Effects<T>), ensuring the semantics match the gate's backpressure intent.
---
Outside diff comments:
In `@crates/amaru-consensus/src/stages/adopt_chain/tests.rs`:
- Around line 115-133: The final expected state in the adopting-tip tests must
account for the DEBUG branch incrementing state.suppressed; update the test
setup to set expected.suppressed = 1 before asserting te_state so the trace
matches the branch that increments suppressed, and apply the same change in all
three adopting tests that build expected and assert te_state (refer to the local
variable expected, the state.suppressed field, and the te_state assertions
paired with the AdoptChainMsg::new inputs).
In `@crates/amaru-consensus/src/stages/track_peers/defer_req_next.rs`:
- Around line 27-48: The pending vector can leak entries for peers that have
been removed because Register no longer carries peer identity and there is no
Cancel; to fix, either restore a Cancel variant on DeferReqNextMsg (e.g., Cancel
{ handler: StageRef<InitiatorMessage> } and remove matching tuples from
DeferReqNext::pending in stage on Cancel) or add pruning logic where entries are
dispatched (e.g., in dispatch_ready or the Poll handling in stage) to detect
dead StageRef handlers and drop their (handler, min_ledger_height) tuples; refer
to DeferReqNextMsg::{Register, Poll}, the DeferReqNext.pending field, and the
stage(...) handler to implement the chosen approach.
---
Nitpick comments:
In `@crates/amaru-consensus/src/stages/track_peers/test_setup.rs`:
- Around line 97-99: The helper te_get_best_chain_hash is inconsistent with its
sibling: instead of constructing the unit effect with
Box::new(GetBestChainHashEffect) use the existing constructor to match style;
replace Box::new(GetBestChainHashEffect) with
Box::new(GetBestChainHashEffect::new()) so
TraceEntry::suspend(Effect::external(at_stage,
Box::new(GetBestChainHashEffect::new()))) mirrors the select_chain test setup.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 5817d650-248f-408a-af6c-b086b3334ef6
📒 Files selected for processing (10)
.github/workflows/snapshot-tests.yml.gitignorecrates/amaru-consensus/src/stages/adopt_chain/mod.rscrates/amaru-consensus/src/stages/adopt_chain/test_setup.rscrates/amaru-consensus/src/stages/adopt_chain/tests.rscrates/amaru-consensus/src/stages/track_peers/defer_req_next.rscrates/amaru-consensus/src/stages/track_peers/mod.rscrates/amaru-consensus/src/stages/track_peers/test_setup.rscrates/amaru-consensus/src/stages/track_peers/tests.rscrates/amaru/src/stages/config.rs
✅ Files skipped from review due to trivial changes (1)
- .gitignore
🚧 Files skipped from review as they are similar to previous changes (2)
- crates/amaru/src/stages/config.rs
- crates/amaru-consensus/src/stages/track_peers/tests.rs
etorreborre
force-pushed
the
rk/preprod-sync
branch
from
d07475a to
e76e9d0
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
crates/amaru-consensus/src/stages/track_peers/mod.rs (1)
39-43:⚠️ Potential issue | 🟠 MajorStill reading the best-chain store tip, not the ledger-applied height.
This helper now calls
Store::get_best_chain_hash()→load_header(), so Line 315 gatesRequestNextusing the consensus store’s best-chain tip rather than the actual ledger-applied tip. That can make the backpressure decision fire on the wrong clock, like trusting the minimap instead of the boss-room door.Either rename this to best-chain-store semantics, or fetch the real ledger-applied height for this gate.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@crates/amaru-consensus/src/stages/track_peers/mod.rs` around lines 39 - 43, The helper ledger_applied_block_height currently reads the consensus store's best-chain tip via Store::get_best_chain_hash() then load_header(), which gates RequestNext on the wrong clock; change it to read the actual ledger-applied tip instead (e.g. call Store::get_ledger_applied_hash() or Store::ledger_applied_header() and then load_header()/block_height() from that hash) so the returned height reflects ledger-applied state; if the store API lacks a ledger_applied accessor, rename the function to best_chain_block_height and update call sites accordingly.
🧹 Nitpick comments (2)
crates/amaru-consensus/src/stages/adopt_chain/mod.rs (2)
114-123: Rate-limited logging reads well — one tiny nitpick on the magic second.The branch logic is spot on: log at
INFOonce the 1s window elapses, resetsuppressed; otherwiseDEBUG+ bump the counter. Very "Groundhog Day but with fewer Bill Murrays".Only nit: the
Duration::from_secs(1)threshold is a policy knob hiding in the middle ofstage. Pulling it into aconst LOG_THROTTLE: Duration = Duration::from_secs(1);at module scope makes intent obvious and easy to tweak later. Take it or leave it.♻️ Optional tidy-up
+const LOG_THROTTLE: Duration = Duration::from_secs(1); + // ... - let now = store.eff().clock().await; - if now.saturating_since(state.last_printed) >= Duration::from_secs(1) { + let now = store.eff().clock().await; + if now.saturating_since(state.last_printed) >= LOG_THROTTLE {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@crates/amaru-consensus/src/stages/adopt_chain/mod.rs` around lines 114 - 123, Introduce a module-level constant for the log throttle duration (e.g. const LOG_THROTTLE: Duration = Duration::from_secs(1);) and replace the inline Duration::from_secs(1) in the adopt tip logging branch with LOG_THROTTLE; keep the existing logic around state.last_printed and state.suppressed unchanged so the INFO/DEBUG decision still uses now.saturating_since(state.last_printed) >= LOG_THROTTLE and the counter reset/increment behavior remains intact.
43-56: Clock origin assumption worth noting for future Clock tweaksThe
last_printed: Instant::at_offset(Duration::from_secs(0))init relies on the assumption that the clock origin stays stable—so the very first adoption (which happens immediately in the simulation) lands atnow - EPOCH < 1sand triggers the DEBUG branch. The tests confirm this is exactly what happens. Solid stuff.That said, if someone ever tinkers with how
pure_stage::Clockinitialises its origin, this implicit dependency could be a sneaky gotcha. Not a blocker at all, but if you fancy future-proofing it, anOption<Instant>— whereNoneforces the first adoption straight to INFO regardless of clock semantics — would be a belt-and-braces move. Totally up to you though; no drama keeping it as is.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@crates/amaru-consensus/src/stages/adopt_chain/mod.rs` around lines 43 - 56, The init currently sets last_printed using Instant::at_offset(...) which depends on Clock origin; change AdoptChain.last_printed from Instant to Option<Instant> and update AdoptChain::new (the constructor) to set last_printed = None so the first adoption is treated as a fresh INFO regardless of clock semantics; update any code paths that read last_printed (e.g., where the DEBUG/INFO decision is made) to treat None as forcing INFO and to store Some(now) after the first print.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@crates/amaru-consensus/src/stages/track_peers/defer_req_next.rs`:
- Around line 27-35: The pending deferred requests are stored as plain
(StageRef<InitiatorMessage>, BlockHeight) so dropped peer/token cannot cancel
them; change the shape used by DeferReqNext/DeferReqNextMsg::Register to include
a cancellation handle (e.g., a CancellationToken, OwnerId, or CancelToken
struct) instead of just StageRef and store Vec<(StageRef<InitiatorMessage>,
BlockHeight, CancelHandle)> in DeferReqNext; update the Register variant to
accept/produce that CancelHandle and update all rollback/removal sites to call
the cancel/remove path using that handle to remove or mark pending entries
cancelled (i.e., add removal logic where peers are rolled back/removed to invoke
the CancelHandle for matching pending entries).
---
Duplicate comments:
In `@crates/amaru-consensus/src/stages/track_peers/mod.rs`:
- Around line 39-43: The helper ledger_applied_block_height currently reads the
consensus store's best-chain tip via Store::get_best_chain_hash() then
load_header(), which gates RequestNext on the wrong clock; change it to read the
actual ledger-applied tip instead (e.g. call Store::get_ledger_applied_hash() or
Store::ledger_applied_header() and then load_header()/block_height() from that
hash) so the returned height reflects ledger-applied state; if the store API
lacks a ledger_applied accessor, rename the function to best_chain_block_height
and update call sites accordingly.
---
Nitpick comments:
In `@crates/amaru-consensus/src/stages/adopt_chain/mod.rs`:
- Around line 114-123: Introduce a module-level constant for the log throttle
duration (e.g. const LOG_THROTTLE: Duration = Duration::from_secs(1);) and
replace the inline Duration::from_secs(1) in the adopt tip logging branch with
LOG_THROTTLE; keep the existing logic around state.last_printed and
state.suppressed unchanged so the INFO/DEBUG decision still uses
now.saturating_since(state.last_printed) >= LOG_THROTTLE and the counter
reset/increment behavior remains intact.
- Around line 43-56: The init currently sets last_printed using
Instant::at_offset(...) which depends on Clock origin; change
AdoptChain.last_printed from Instant to Option<Instant> and update
AdoptChain::new (the constructor) to set last_printed = None so the first
adoption is treated as a fresh INFO regardless of clock semantics; update any
code paths that read last_printed (e.g., where the DEBUG/INFO decision is made)
to treat None as forcing INFO and to store Some(now) after the first print.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 520b847d-736c-450a-837f-650ca01ca5da
📒 Files selected for processing (8)
crates/amaru-consensus/src/stages/adopt_chain/mod.rscrates/amaru-consensus/src/stages/adopt_chain/test_setup.rscrates/amaru-consensus/src/stages/adopt_chain/tests.rscrates/amaru-consensus/src/stages/track_peers/defer_req_next.rscrates/amaru-consensus/src/stages/track_peers/mod.rscrates/amaru-consensus/src/stages/track_peers/test_setup.rscrates/amaru-consensus/src/stages/track_peers/tests.rscrates/amaru/src/stages/config.rs
🚧 Files skipped from review as they are similar to previous changes (2)
- crates/amaru/src/stages/config.rs
- crates/amaru-consensus/src/stages/track_peers/tests.rs
| pub enum DeferReqNextMsg { | ||
| Register { | ||
| peer: Peer, | ||
| handler: StageRef<InitiatorMessage>, | ||
| min_ledger_height: BlockHeight, | ||
| }, | ||
| /// Drop any deferred `RequestNext` for this peer (e.g. after rollback). | ||
| Cancel { | ||
| peer: Peer, | ||
| }, | ||
| Register { handler: StageRef<InitiatorMessage>, min_ledger_height: BlockHeight }, | ||
| Poll, | ||
| } | ||
|
|
||
| #[derive(Debug, Clone, PartialEq, serde::Serialize, serde::Deserialize)] | ||
| pub struct DeferReqNext { | ||
| pub poll_interval_ms: u64, | ||
| pub pending: Vec<(Peer, StageRef<InitiatorMessage>, BlockHeight)>, | ||
| pub pending: Vec<(StageRef<InitiatorMessage>, BlockHeight)>, |
There was a problem hiding this comment.
Keep deferred requests cancellable by owner.
Dropping the peer/cancel token means rollback or peer removal can’t clear a pending deferred RequestNext. If that chain switches away or the handler goes stale before min_ledger_height, this stage can later poke the wrong handler — bit of a Matrix “wrong phone line” moment.
Consider keeping a peer/token in pending and restoring a Cancel path from rollback/removal sites.
🛠️ Sketch of the safer shape
-use amaru_kernel::BlockHeight;
+use amaru_kernel::{BlockHeight, Peer};
pub enum DeferReqNextMsg {
- Register { handler: StageRef<InitiatorMessage>, min_ledger_height: BlockHeight },
+ Register { peer: Peer, handler: StageRef<InitiatorMessage>, min_ledger_height: BlockHeight },
+ Cancel { peer: Peer },
Poll,
}
pub struct DeferReqNext {
pub poll_interval_ms: u64,
- pub pending: Vec<(StageRef<InitiatorMessage>, BlockHeight)>,
+ pub pending: Vec<(Peer, StageRef<InitiatorMessage>, BlockHeight)>,
}
match msg {
- Register { handler, min_ledger_height } => {
- state.pending.push((handler, min_ledger_height));
+ Register { peer, handler, min_ledger_height } => {
+ state.pending.push((peer, handler, min_ledger_height));
+ }
+ Cancel { peer } => {
+ state.pending.retain(|(pending_peer, _, _)| pending_peer != &peer);
}
Poll => {
dispatch_ready(&mut state, &eff).await;
let poll = Duration::from_millis(state.poll_interval_ms.max(1));
eff.schedule_after(Poll, poll).await;
@@
-for (handler, min_h) in std::mem::take(&mut state.pending) {
+for (peer, handler, min_h) in std::mem::take(&mut state.pending) {
if ledger_height >= min_h {
eff.send(&handler, InitiatorMessage::RequestNext).await;
} else {
- remaining.push((handler, min_h));
+ remaining.push((peer, handler, min_h));
}
}Also applies to: 47-49, 59-69
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@crates/amaru-consensus/src/stages/track_peers/defer_req_next.rs` around lines
27 - 35, The pending deferred requests are stored as plain
(StageRef<InitiatorMessage>, BlockHeight) so dropped peer/token cannot cancel
them; change the shape used by DeferReqNext/DeferReqNextMsg::Register to include
a cancellation handle (e.g., a CancellationToken, OwnerId, or CancelToken
struct) instead of just StageRef and store Vec<(StageRef<InitiatorMessage>,
BlockHeight, CancelHandle)> in DeferReqNext; update the Register variant to
accept/produce that CancelHandle and update all rollback/removal sites to call
the cancel/remove path using that handle to remove or mark pending entries
cancelled (i.e., add removal logic where peers are rolled back/removed to invoke
the CancelHandle for matching pending entries).
…idations. Signed-off-by: KtorZ <matthias.benkort@gmail.com>
Signed-off-by: KtorZ <matthias.benkort@gmail.com>
Signed-off-by: KtorZ <matthias.benkort@gmail.com>
… regression) Signed-off-by: Roland Kuhn <rk@rkuhn.info>
Signed-off-by: Roland Kuhn <rk@rkuhn.info>
Signed-off-by: Roland Kuhn <rk@rkuhn.info>
also teach dump-chain-db a new trick: show ancestors of given point with validity Signed-off-by: Roland Kuhn <rk@rkuhn.info>
For preview there is a rather weird effect slowing it down now, looks like the Cardano node throttles chainsync to 4/sec. Signed-off-by: Roland Kuhn <rk@rkuhn.info>
2 participants
closes #658
Summary by CodeRabbit