Skip to content

fuzz: add explicit chanmon manager persistence commands #4631

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
joostjager wants to merge 3 commits into
base: main
Choose a base branch
from
+119 −47
Open

fuzz: add explicit chanmon manager persistence commands #4631

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
b33526e
Add explicit chanmon manager persistence commands
joostjager May 21, 2026
bbeba3e
Refactor chanmon payment tracker helpers
joostjager May 22, 2026
c18fab5
Track chanmon payment persistence generations
joostjager May 22, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 11 additions & 2 deletions fuzz/src/chanmon_consistency.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2860,6 +2860,7 @@ impl<'a, Out: Output + MaybeSend + MaybeSync> Harness<'a, Out> {
}

fn restart_node(&mut self, node_idx: usize, v: u8, router: &'a FuzzRouter) {
self.nodes[node_idx].checkpoint_manager_persistence();
Copy link
Copy Markdown
Contributor Author

@joostjager joostjager May 21, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a bit fake? Perhaps we should just restart from the latest persisted state, but that also means that payment tracking may be off a bit.

Copy link
Copy Markdown
Collaborator

@TheBlueMatt TheBlueMatt May 21, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, I mean this is kinda emulating the behavior we had before where we persist on every iteration, except now we only make sure we persist every time before we read it...Indeed, we'd have to handle the payment tracking parts, though :/.

Copy link
Copy Markdown
Contributor Author

@joostjager joostjager May 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it was quite the same, because we were potentially stacking up monitor writes a bit more. But I added code to handle the payment tracking to make it more realistic.

I really hope we can improve the current persistence model situation soon. Keeping the separate monitor and manager persistence model coherent is such a time sink.

match node_idx {
0 => {
self.ab_link.disconnect_for_reload(0, &self.nodes, &mut self.queues);
Expand Down Expand Up @@ -3116,6 +3117,16 @@ pub fn do_test<Out: Output + MaybeSend + MaybeSync>(data: &[u8], out: Out) {
0x88 => harness.nodes[2].bump_fee_estimate(harness.chan_type),
0x89 => harness.nodes[2].reset_fee_estimate(),

0x90 => {
harness.nodes[0].checkpoint_manager_persistence();
},
0x91 => {
harness.nodes[1].checkpoint_manager_persistence();
},
0x92 => {
harness.nodes[2].checkpoint_manager_persistence();
},

0xa0 => {
if !cfg!(splicing) {
break 'fuzz_loop;
Expand Down Expand Up @@ -3370,8 +3381,6 @@ pub fn do_test<Out: Output + MaybeSend + MaybeSync>(data: &[u8], out: Out) {
},
_ => break 'fuzz_loop,
}

harness.checkpoint_manager_persistences();
}
harness.finish();
}
Expand Down
Loading