From 48d4bfbf9f8c937b5cb442256ef7884a752c1d40 Mon Sep 17 00:00:00 2001 From: xdustinface Date: Mon, 9 Feb 2026 10:51:17 +0100 Subject: [PATCH] fix: avoid re-inserting previous filter header on sync resume On restart, `start_download()` unconditionally set `checkpoint_start_height` which caused `process_cfheaders()` to store `previous_filter_header` at an offset that already contained data, triggering a `debug_assert` panic. Only set `checkpoint_start_height` when filter storage is empty not when resuming from existing stored state. --- dash-spv/src/sync/filter_headers/manager.rs | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/dash-spv/src/sync/filter_headers/manager.rs b/dash-spv/src/sync/filter_headers/manager.rs index 9f051acc8..cb49adf3c 100644 --- a/dash-spv/src/sync/filter_headers/manager.rs +++ b/dash-spv/src/sync/filter_headers/manager.rs @@ -138,8 +138,10 @@ impl FilterHeadersManager self.progress.block_header_tip_height() ); - // Track checkpoint start height for storing prev header on first batch - if start_height > 0 { + // Track checkpoint start height for storing prev header on first batch. + // Only needed on fresh checkpoint sync (no existing filter headers). + // On resume, start_height-1 is already stored so re-inserting would panic in debug builds. + if start_height > 0 && filter_headers_tip == 0 { self.checkpoint_start_height = Some(start_height); }