Fuzz reloading with a stale monitor in chanmon_consistency by TheBlueMatt · Pull Request #3113 · lightningdevkit/rust-lightning

TheBlueMatt · 2024-06-10T18:43:04Z

Now that we are gearing up to support fully async monitor storage, we really need to fuzz monitor updates not completing before a reload, which we do here in the chanmon_consistency fuzzer.

While there are more parts to async monitor updating that we need to fuzz, this at least gets us started by having basic async restart cases handled. In the future, we should extend this to make sure some basic properties (eg claim/balance consistency) remain true through chanmon_consistency runs.

codecov-commenter · 2024-06-10T21:08:29Z

Codecov Report

Attention: Patch coverage is 97.50000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 90.65%. Comparing base (1d0c6c6) to head (2a0c900).
Report is 15 commits behind head on main.

Files	Patch %	Lines
lightning/src/ln/chanmon_update_fail_tests.rs	97.46%	2 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #3113 +/- ##
==========================================
+ Coverage 89.84% 90.65% +0.80% 
==========================================
Files 119 119 Lines 97811 102825 +5014 Branches 97811 102825 +5014 ==========================================
+ Hits 87883 93217 +5334 + Misses 7364 7108 -256 + Partials 2564 2500 -64

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

tnull

Generally LGTM, just a few questions/comments.

tnull · 2024-06-11T10:52:28Z

+ &|v: &mut Vec<_>| if !v.is_empty() { Some(v.remove(0)) } else { None }),
+ 0xf1 =>
+ complete_monitor_update(&monitor_a, &chan_1_funding,
+ &|v: &mut Vec<_>| if v.len() > 1 { Some(v.remove(1)) } else { None }),


Not quite sure why we alternate between 0 and 1 here? Would we gain anything in terms of coverage by choosing randomly from 0..len?

We can't chose randomly because fuzzer results need to be deterministic based on the input. We could read another byte of fuzz input and use that, but we really want the fuzz input to be as dense as possible, so using a single bit for it seems sufficient. I'm not sure that we'd have any issues that can't be expressed through finishing (first, second, last), but could see some issues arising where we need to finish something in the middle that isnt first or last.

We can't chose randomly because fuzzer results need to be deterministic based on the input. We could read another byte of fuzz input and use that
Right, I imagined the latter.
but we really want the fuzz input to be as dense as possible, so using a single bit for it seems sufficient. I'm not sure that we'd have any issues that can't be expressed through finishing (first, second, last), but could see some issues arising where we need to finish something in the middle that isnt first or last.
Yeah, that's why I thought covering the entire Vec might be worth it, but maybe it's not too important.

TheBlueMatt · 2024-06-12T02:27:58Z

Addressed feedback.

tnull · 2024-06-12T08:57:44Z

Addressed feedback.

Unfortunately the new test now reliably fails:

thread 'ln::chanmon_update_fail_tests::test_sync_async_persist_doesnt_hang' panicked at 'explicit panic', lightning/src/ln/chanmon_update_fail_tests.rs:3410:14

TheBlueMatt · 2024-06-12T14:11:22Z

Ugh, sorry, pushed right before bed last night and didn't test enough :/

valentinewallace · 2024-06-12T14:48:39Z

LGTM, feel free to squash IMO.

Now that we are gearing up to support fully async monitor storage, we really need to fuzz monitor updates not completing before a reload, which we do here in the `chanmon_consistency` fuzzer. While there are more parts to async monitor updating that we need to fuzz, this at least gets us started by having basic async restart cases handled. In the future, we should extend this to make sure some basic properties (eg claim/balance consistency) remain true through `chanmon_consistency` runs.

When we have `ChannelMonitorUpdate`s which are completing both synchronously and asynchronously, we need to consider a channel as unblocked based on the `ChannelManager` monitor update queue, rather than by checking the `update_id`s. Consider the case where a channel is updated, leading to a `ChannelMonitorUpdate` which completes asynchronously. The update completes, but prior to the `ChannelManager` receiving the `MonitorEvent::Completed` it generates a further `ChannelMonitorUpdate`. This second update completes synchronously. As a result, when the `MonitorEvent` is processed, the event's `monitor_update_id` is the first update, but there are no updates queued and the channel should be free to return to be unblocked. Here we fix this by looking only at the `ChannelManager` update queue, rather than the update_id of the `MonitorEvent`. While we don't anticipate many users having both synchronous and asynchronous persists in the same application, there isn't much cost to supporting it, which we do here. Found by the chanmon_consistency target.

TheBlueMatt · 2024-06-12T15:32:48Z

Squashed without further changes.

TheBlueMatt · 2024-06-10T18:43:04Z

Now that we are gearing up to support fully async monitor storage, we really need to fuzz monitor updates not completing before a reload, which we do here in the chanmon_consistency fuzzer.

While there are more parts to async monitor updating that we need to fuzz, this at least gets us started by having basic async restart cases handled. In the future, we should extend this to make sure some basic properties (eg claim/balance consistency) remain true through chanmon_consistency runs.

codecov-commenter · 2024-06-10T21:08:29Z

Codecov Report

Attention: Patch coverage is 97.50000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 90.65%. Comparing base (1d0c6c6) to head (2a0c900).
Report is 15 commits behind head on main.

Files	Patch %	Lines
lightning/src/ln/chanmon_update_fail_tests.rs	97.46%	2 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #3113 +/- ##
==========================================
+ Coverage 89.84% 90.65% +0.80% 
==========================================
Files 119 119 Lines 97811 102825 +5014 Branches 97811 102825 +5014 ==========================================
+ Hits 87883 93217 +5334 + Misses 7364 7108 -256 + Partials 2564 2500 -64

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

tnull

Generally LGTM, just a few questions/comments.

tnull · 2024-06-11T10:52:28Z

+ &|v: &mut Vec<_>| if !v.is_empty() { Some(v.remove(0)) } else { None }),
+ 0xf1 =>
+ complete_monitor_update(&monitor_a, &chan_1_funding,
+ &|v: &mut Vec<_>| if v.len() > 1 { Some(v.remove(1)) } else { None }),


Not quite sure why we alternate between 0 and 1 here? Would we gain anything in terms of coverage by choosing randomly from 0..len?

We can't chose randomly because fuzzer results need to be deterministic based on the input. We could read another byte of fuzz input and use that, but we really want the fuzz input to be as dense as possible, so using a single bit for it seems sufficient. I'm not sure that we'd have any issues that can't be expressed through finishing (first, second, last), but could see some issues arising where we need to finish something in the middle that isnt first or last.

We can't chose randomly because fuzzer results need to be deterministic based on the input. We could read another byte of fuzz input and use that
Right, I imagined the latter.
but we really want the fuzz input to be as dense as possible, so using a single bit for it seems sufficient. I'm not sure that we'd have any issues that can't be expressed through finishing (first, second, last), but could see some issues arising where we need to finish something in the middle that isnt first or last.
Yeah, that's why I thought covering the entire Vec might be worth it, but maybe it's not too important.

TheBlueMatt · 2024-06-12T02:27:58Z

Addressed feedback.

tnull · 2024-06-12T08:57:44Z

Addressed feedback.

Unfortunately the new test now reliably fails:

thread 'ln::chanmon_update_fail_tests::test_sync_async_persist_doesnt_hang' panicked at 'explicit panic', lightning/src/ln/chanmon_update_fail_tests.rs:3410:14

TheBlueMatt · 2024-06-12T14:11:22Z

Ugh, sorry, pushed right before bed last night and didn't test enough :/

valentinewallace · 2024-06-12T14:48:39Z

LGTM, feel free to squash IMO.

Now that we are gearing up to support fully async monitor storage, we really need to fuzz monitor updates not completing before a reload, which we do here in the `chanmon_consistency` fuzzer. While there are more parts to async monitor updating that we need to fuzz, this at least gets us started by having basic async restart cases handled. In the future, we should extend this to make sure some basic properties (eg claim/balance consistency) remain true through `chanmon_consistency` runs.

When we have `ChannelMonitorUpdate`s which are completing both synchronously and asynchronously, we need to consider a channel as unblocked based on the `ChannelManager` monitor update queue, rather than by checking the `update_id`s. Consider the case where a channel is updated, leading to a `ChannelMonitorUpdate` which completes asynchronously. The update completes, but prior to the `ChannelManager` receiving the `MonitorEvent::Completed` it generates a further `ChannelMonitorUpdate`. This second update completes synchronously. As a result, when the `MonitorEvent` is processed, the event's `monitor_update_id` is the first update, but there are no updates queued and the channel should be free to return to be unblocked. Here we fix this by looking only at the `ChannelManager` update queue, rather than the update_id of the `MonitorEvent`. While we don't anticipate many users having both synchronous and asynchronous persists in the same application, there isn't much cost to supporting it, which we do here. Found by the chanmon_consistency target.

TheBlueMatt · 2024-06-12T15:32:48Z

Squashed without further changes.

TheBlueMatt · 2024-06-10T18:43:04Z

Now that we are gearing up to support fully async monitor storage, we really need to fuzz monitor updates not completing before a reload, which we do here in the chanmon_consistency fuzzer.

While there are more parts to async monitor updating that we need to fuzz, this at least gets us started by having basic async restart cases handled. In the future, we should extend this to make sure some basic properties (eg claim/balance consistency) remain true through chanmon_consistency runs.

codecov-commenter · 2024-06-10T21:08:29Z

Codecov Report

Attention: Patch coverage is 97.50000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 90.65%. Comparing base (1d0c6c6) to head (2a0c900).
Report is 15 commits behind head on main.

Files	Patch %	Lines
lightning/src/ln/chanmon_update_fail_tests.rs	97.46%	2 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #3113 +/- ##
==========================================
+ Coverage 89.84% 90.65% +0.80% 
==========================================
Files 119 119 Lines 97811 102825 +5014 Branches 97811 102825 +5014 ==========================================
+ Hits 87883 93217 +5334 + Misses 7364 7108 -256 + Partials 2564 2500 -64

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

tnull

Generally LGTM, just a few questions/comments.

tnull · 2024-06-11T10:52:28Z

+ &|v: &mut Vec<_>| if !v.is_empty() { Some(v.remove(0)) } else { None }),
+ 0xf1 =>
+ complete_monitor_update(&monitor_a, &chan_1_funding,
+ &|v: &mut Vec<_>| if v.len() > 1 { Some(v.remove(1)) } else { None }),


Not quite sure why we alternate between 0 and 1 here? Would we gain anything in terms of coverage by choosing randomly from 0..len?

We can't chose randomly because fuzzer results need to be deterministic based on the input. We could read another byte of fuzz input and use that, but we really want the fuzz input to be as dense as possible, so using a single bit for it seems sufficient. I'm not sure that we'd have any issues that can't be expressed through finishing (first, second, last), but could see some issues arising where we need to finish something in the middle that isnt first or last.

We can't chose randomly because fuzzer results need to be deterministic based on the input. We could read another byte of fuzz input and use that
Right, I imagined the latter.
but we really want the fuzz input to be as dense as possible, so using a single bit for it seems sufficient. I'm not sure that we'd have any issues that can't be expressed through finishing (first, second, last), but could see some issues arising where we need to finish something in the middle that isnt first or last.
Yeah, that's why I thought covering the entire Vec might be worth it, but maybe it's not too important.

TheBlueMatt · 2024-06-12T02:27:58Z

Addressed feedback.

tnull · 2024-06-12T08:57:44Z

Addressed feedback.

Unfortunately the new test now reliably fails:

thread 'ln::chanmon_update_fail_tests::test_sync_async_persist_doesnt_hang' panicked at 'explicit panic', lightning/src/ln/chanmon_update_fail_tests.rs:3410:14

TheBlueMatt · 2024-06-12T14:11:22Z

Ugh, sorry, pushed right before bed last night and didn't test enough :/

valentinewallace · 2024-06-12T14:48:39Z

LGTM, feel free to squash IMO.

Now that we are gearing up to support fully async monitor storage, we really need to fuzz monitor updates not completing before a reload, which we do here in the `chanmon_consistency` fuzzer. While there are more parts to async monitor updating that we need to fuzz, this at least gets us started by having basic async restart cases handled. In the future, we should extend this to make sure some basic properties (eg claim/balance consistency) remain true through `chanmon_consistency` runs.

When we have `ChannelMonitorUpdate`s which are completing both synchronously and asynchronously, we need to consider a channel as unblocked based on the `ChannelManager` monitor update queue, rather than by checking the `update_id`s. Consider the case where a channel is updated, leading to a `ChannelMonitorUpdate` which completes asynchronously. The update completes, but prior to the `ChannelManager` receiving the `MonitorEvent::Completed` it generates a further `ChannelMonitorUpdate`. This second update completes synchronously. As a result, when the `MonitorEvent` is processed, the event's `monitor_update_id` is the first update, but there are no updates queued and the channel should be free to return to be unblocked. Here we fix this by looking only at the `ChannelManager` update queue, rather than the update_id of the `MonitorEvent`. While we don't anticipate many users having both synchronous and asynchronous persists in the same application, there isn't much cost to supporting it, which we do here. Found by the chanmon_consistency target.

TheBlueMatt · 2024-06-12T15:32:48Z

Squashed without further changes.

TheBlueMatt · 2024-06-10T18:43:04Z

Now that we are gearing up to support fully async monitor storage, we really need to fuzz monitor updates not completing before a reload, which we do here in the chanmon_consistency fuzzer.

While there are more parts to async monitor updating that we need to fuzz, this at least gets us started by having basic async restart cases handled. In the future, we should extend this to make sure some basic properties (eg claim/balance consistency) remain true through chanmon_consistency runs.

codecov-commenter · 2024-06-10T21:08:29Z

Codecov Report

Attention: Patch coverage is 97.50000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 90.65%. Comparing base (1d0c6c6) to head (2a0c900).
Report is 15 commits behind head on main.

Files	Patch %	Lines
lightning/src/ln/chanmon_update_fail_tests.rs	97.46%	2 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #3113 +/- ##
==========================================
+ Coverage 89.84% 90.65% +0.80% 
==========================================
Files 119 119 Lines 97811 102825 +5014 Branches 97811 102825 +5014 ==========================================
+ Hits 87883 93217 +5334 + Misses 7364 7108 -256 + Partials 2564 2500 -64

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

tnull

Generally LGTM, just a few questions/comments.

tnull · 2024-06-11T10:52:28Z

+ &|v: &mut Vec<_>| if !v.is_empty() { Some(v.remove(0)) } else { None }),
+ 0xf1 =>
+ complete_monitor_update(&monitor_a, &chan_1_funding,
+ &|v: &mut Vec<_>| if v.len() > 1 { Some(v.remove(1)) } else { None }),


Not quite sure why we alternate between 0 and 1 here? Would we gain anything in terms of coverage by choosing randomly from 0..len?

We can't chose randomly because fuzzer results need to be deterministic based on the input. We could read another byte of fuzz input and use that, but we really want the fuzz input to be as dense as possible, so using a single bit for it seems sufficient. I'm not sure that we'd have any issues that can't be expressed through finishing (first, second, last), but could see some issues arising where we need to finish something in the middle that isnt first or last.

We can't chose randomly because fuzzer results need to be deterministic based on the input. We could read another byte of fuzz input and use that
Right, I imagined the latter.
but we really want the fuzz input to be as dense as possible, so using a single bit for it seems sufficient. I'm not sure that we'd have any issues that can't be expressed through finishing (first, second, last), but could see some issues arising where we need to finish something in the middle that isnt first or last.
Yeah, that's why I thought covering the entire Vec might be worth it, but maybe it's not too important.

TheBlueMatt · 2024-06-12T02:27:58Z

Addressed feedback.

tnull · 2024-06-12T08:57:44Z

Addressed feedback.

Unfortunately the new test now reliably fails:

thread 'ln::chanmon_update_fail_tests::test_sync_async_persist_doesnt_hang' panicked at 'explicit panic', lightning/src/ln/chanmon_update_fail_tests.rs:3410:14

TheBlueMatt · 2024-06-12T14:11:22Z

Ugh, sorry, pushed right before bed last night and didn't test enough :/

valentinewallace · 2024-06-12T14:48:39Z

LGTM, feel free to squash IMO.

Now that we are gearing up to support fully async monitor storage, we really need to fuzz monitor updates not completing before a reload, which we do here in the `chanmon_consistency` fuzzer. While there are more parts to async monitor updating that we need to fuzz, this at least gets us started by having basic async restart cases handled. In the future, we should extend this to make sure some basic properties (eg claim/balance consistency) remain true through `chanmon_consistency` runs.

When we have `ChannelMonitorUpdate`s which are completing both synchronously and asynchronously, we need to consider a channel as unblocked based on the `ChannelManager` monitor update queue, rather than by checking the `update_id`s. Consider the case where a channel is updated, leading to a `ChannelMonitorUpdate` which completes asynchronously. The update completes, but prior to the `ChannelManager` receiving the `MonitorEvent::Completed` it generates a further `ChannelMonitorUpdate`. This second update completes synchronously. As a result, when the `MonitorEvent` is processed, the event's `monitor_update_id` is the first update, but there are no updates queued and the channel should be free to return to be unblocked. Here we fix this by looking only at the `ChannelManager` update queue, rather than the update_id of the `MonitorEvent`. While we don't anticipate many users having both synchronous and asynchronous persists in the same application, there isn't much cost to supporting it, which we do here. Found by the chanmon_consistency target.

TheBlueMatt · 2024-06-12T15:32:48Z

Squashed without further changes.

TheBlueMatt · 2024-06-10T18:43:04Z

Now that we are gearing up to support fully async monitor storage, we really need to fuzz monitor updates not completing before a reload, which we do here in the chanmon_consistency fuzzer.

While there are more parts to async monitor updating that we need to fuzz, this at least gets us started by having basic async restart cases handled. In the future, we should extend this to make sure some basic properties (eg claim/balance consistency) remain true through chanmon_consistency runs.

codecov-commenter · 2024-06-10T21:08:29Z

Codecov Report

Attention: Patch coverage is 97.50000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 90.65%. Comparing base (1d0c6c6) to head (2a0c900).
Report is 15 commits behind head on main.

Files	Patch %	Lines
lightning/src/ln/chanmon_update_fail_tests.rs	97.46%	2 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #3113 +/- ##
==========================================
+ Coverage 89.84% 90.65% +0.80% 
==========================================
Files 119 119 Lines 97811 102825 +5014 Branches 97811 102825 +5014 ==========================================
+ Hits 87883 93217 +5334 + Misses 7364 7108 -256 + Partials 2564 2500 -64

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

tnull

Generally LGTM, just a few questions/comments.

tnull · 2024-06-11T10:52:28Z

+ &|v: &mut Vec<_>| if !v.is_empty() { Some(v.remove(0)) } else { None }),
+ 0xf1 =>
+ complete_monitor_update(&monitor_a, &chan_1_funding,
+ &|v: &mut Vec<_>| if v.len() > 1 { Some(v.remove(1)) } else { None }),


Not quite sure why we alternate between 0 and 1 here? Would we gain anything in terms of coverage by choosing randomly from 0..len?

We can't chose randomly because fuzzer results need to be deterministic based on the input. We could read another byte of fuzz input and use that, but we really want the fuzz input to be as dense as possible, so using a single bit for it seems sufficient. I'm not sure that we'd have any issues that can't be expressed through finishing (first, second, last), but could see some issues arising where we need to finish something in the middle that isnt first or last.

We can't chose randomly because fuzzer results need to be deterministic based on the input. We could read another byte of fuzz input and use that
Right, I imagined the latter.
but we really want the fuzz input to be as dense as possible, so using a single bit for it seems sufficient. I'm not sure that we'd have any issues that can't be expressed through finishing (first, second, last), but could see some issues arising where we need to finish something in the middle that isnt first or last.
Yeah, that's why I thought covering the entire Vec might be worth it, but maybe it's not too important.

TheBlueMatt · 2024-06-12T02:27:58Z

Addressed feedback.

tnull · 2024-06-12T08:57:44Z

Addressed feedback.

Unfortunately the new test now reliably fails:

thread 'ln::chanmon_update_fail_tests::test_sync_async_persist_doesnt_hang' panicked at 'explicit panic', lightning/src/ln/chanmon_update_fail_tests.rs:3410:14

TheBlueMatt · 2024-06-12T14:11:22Z

Ugh, sorry, pushed right before bed last night and didn't test enough :/

valentinewallace · 2024-06-12T14:48:39Z

LGTM, feel free to squash IMO.

Now that we are gearing up to support fully async monitor storage, we really need to fuzz monitor updates not completing before a reload, which we do here in the `chanmon_consistency` fuzzer. While there are more parts to async monitor updating that we need to fuzz, this at least gets us started by having basic async restart cases handled. In the future, we should extend this to make sure some basic properties (eg claim/balance consistency) remain true through `chanmon_consistency` runs.

When we have `ChannelMonitorUpdate`s which are completing both synchronously and asynchronously, we need to consider a channel as unblocked based on the `ChannelManager` monitor update queue, rather than by checking the `update_id`s. Consider the case where a channel is updated, leading to a `ChannelMonitorUpdate` which completes asynchronously. The update completes, but prior to the `ChannelManager` receiving the `MonitorEvent::Completed` it generates a further `ChannelMonitorUpdate`. This second update completes synchronously. As a result, when the `MonitorEvent` is processed, the event's `monitor_update_id` is the first update, but there are no updates queued and the channel should be free to return to be unblocked. Here we fix this by looking only at the `ChannelManager` update queue, rather than the update_id of the `MonitorEvent`. While we don't anticipate many users having both synchronous and asynchronous persists in the same application, there isn't much cost to supporting it, which we do here. Found by the chanmon_consistency target.

TheBlueMatt · 2024-06-12T15:32:48Z

Squashed without further changes.

TheBlueMatt · 2024-06-10T18:43:04Z

Now that we are gearing up to support fully async monitor storage, we really need to fuzz monitor updates not completing before a reload, which we do here in the chanmon_consistency fuzzer.

While there are more parts to async monitor updating that we need to fuzz, this at least gets us started by having basic async restart cases handled. In the future, we should extend this to make sure some basic properties (eg claim/balance consistency) remain true through chanmon_consistency runs.

codecov-commenter · 2024-06-10T21:08:29Z

Codecov Report

Attention: Patch coverage is 97.50000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 90.65%. Comparing base (1d0c6c6) to head (2a0c900).
Report is 15 commits behind head on main.

Files	Patch %	Lines
lightning/src/ln/chanmon_update_fail_tests.rs	97.46%	2 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #3113 +/- ##
==========================================
+ Coverage 89.84% 90.65% +0.80% 
==========================================
Files 119 119 Lines 97811 102825 +5014 Branches 97811 102825 +5014 ==========================================
+ Hits 87883 93217 +5334 + Misses 7364 7108 -256 + Partials 2564 2500 -64

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

tnull

Generally LGTM, just a few questions/comments.

tnull · 2024-06-11T10:52:28Z

+ &|v: &mut Vec<_>| if !v.is_empty() { Some(v.remove(0)) } else { None }),
+ 0xf1 =>
+ complete_monitor_update(&monitor_a, &chan_1_funding,
+ &|v: &mut Vec<_>| if v.len() > 1 { Some(v.remove(1)) } else { None }),


Not quite sure why we alternate between 0 and 1 here? Would we gain anything in terms of coverage by choosing randomly from 0..len?

We can't chose randomly because fuzzer results need to be deterministic based on the input. We could read another byte of fuzz input and use that, but we really want the fuzz input to be as dense as possible, so using a single bit for it seems sufficient. I'm not sure that we'd have any issues that can't be expressed through finishing (first, second, last), but could see some issues arising where we need to finish something in the middle that isnt first or last.

We can't chose randomly because fuzzer results need to be deterministic based on the input. We could read another byte of fuzz input and use that
Right, I imagined the latter.
but we really want the fuzz input to be as dense as possible, so using a single bit for it seems sufficient. I'm not sure that we'd have any issues that can't be expressed through finishing (first, second, last), but could see some issues arising where we need to finish something in the middle that isnt first or last.
Yeah, that's why I thought covering the entire Vec might be worth it, but maybe it's not too important.

TheBlueMatt · 2024-06-12T02:27:58Z

Addressed feedback.

tnull · 2024-06-12T08:57:44Z

Addressed feedback.

Unfortunately the new test now reliably fails:

thread 'ln::chanmon_update_fail_tests::test_sync_async_persist_doesnt_hang' panicked at 'explicit panic', lightning/src/ln/chanmon_update_fail_tests.rs:3410:14

TheBlueMatt · 2024-06-12T14:11:22Z

Ugh, sorry, pushed right before bed last night and didn't test enough :/

valentinewallace · 2024-06-12T14:48:39Z

LGTM, feel free to squash IMO.

Now that we are gearing up to support fully async monitor storage, we really need to fuzz monitor updates not completing before a reload, which we do here in the `chanmon_consistency` fuzzer. While there are more parts to async monitor updating that we need to fuzz, this at least gets us started by having basic async restart cases handled. In the future, we should extend this to make sure some basic properties (eg claim/balance consistency) remain true through `chanmon_consistency` runs.

When we have `ChannelMonitorUpdate`s which are completing both synchronously and asynchronously, we need to consider a channel as unblocked based on the `ChannelManager` monitor update queue, rather than by checking the `update_id`s. Consider the case where a channel is updated, leading to a `ChannelMonitorUpdate` which completes asynchronously. The update completes, but prior to the `ChannelManager` receiving the `MonitorEvent::Completed` it generates a further `ChannelMonitorUpdate`. This second update completes synchronously. As a result, when the `MonitorEvent` is processed, the event's `monitor_update_id` is the first update, but there are no updates queued and the channel should be free to return to be unblocked. Here we fix this by looking only at the `ChannelManager` update queue, rather than the update_id of the `MonitorEvent`. While we don't anticipate many users having both synchronous and asynchronous persists in the same application, there isn't much cost to supporting it, which we do here. Found by the chanmon_consistency target.

TheBlueMatt · 2024-06-12T15:32:48Z

Squashed without further changes.

TheBlueMatt · 2024-06-10T18:43:04Z

Now that we are gearing up to support fully async monitor storage, we really need to fuzz monitor updates not completing before a reload, which we do here in the chanmon_consistency fuzzer.

While there are more parts to async monitor updating that we need to fuzz, this at least gets us started by having basic async restart cases handled. In the future, we should extend this to make sure some basic properties (eg claim/balance consistency) remain true through chanmon_consistency runs.

codecov-commenter · 2024-06-10T21:08:29Z

Codecov Report

Attention: Patch coverage is 97.50000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 90.65%. Comparing base (1d0c6c6) to head (2a0c900).
Report is 15 commits behind head on main.

Files	Patch %	Lines
lightning/src/ln/chanmon_update_fail_tests.rs	97.46%	2 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #3113 +/- ##
==========================================
+ Coverage 89.84% 90.65% +0.80% 
==========================================
Files 119 119 Lines 97811 102825 +5014 Branches 97811 102825 +5014 ==========================================
+ Hits 87883 93217 +5334 + Misses 7364 7108 -256 + Partials 2564 2500 -64

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

tnull

Generally LGTM, just a few questions/comments.

tnull · 2024-06-11T10:52:28Z

+ &|v: &mut Vec<_>| if !v.is_empty() { Some(v.remove(0)) } else { None }),
+ 0xf1 =>
+ complete_monitor_update(&monitor_a, &chan_1_funding,
+ &|v: &mut Vec<_>| if v.len() > 1 { Some(v.remove(1)) } else { None }),


Not quite sure why we alternate between 0 and 1 here? Would we gain anything in terms of coverage by choosing randomly from 0..len?

We can't chose randomly because fuzzer results need to be deterministic based on the input. We could read another byte of fuzz input and use that, but we really want the fuzz input to be as dense as possible, so using a single bit for it seems sufficient. I'm not sure that we'd have any issues that can't be expressed through finishing (first, second, last), but could see some issues arising where we need to finish something in the middle that isnt first or last.

We can't chose randomly because fuzzer results need to be deterministic based on the input. We could read another byte of fuzz input and use that
Right, I imagined the latter.
but we really want the fuzz input to be as dense as possible, so using a single bit for it seems sufficient. I'm not sure that we'd have any issues that can't be expressed through finishing (first, second, last), but could see some issues arising where we need to finish something in the middle that isnt first or last.
Yeah, that's why I thought covering the entire Vec might be worth it, but maybe it's not too important.

TheBlueMatt · 2024-06-12T02:27:58Z

Addressed feedback.

tnull · 2024-06-12T08:57:44Z

Addressed feedback.

Unfortunately the new test now reliably fails:

thread 'ln::chanmon_update_fail_tests::test_sync_async_persist_doesnt_hang' panicked at 'explicit panic', lightning/src/ln/chanmon_update_fail_tests.rs:3410:14

TheBlueMatt · 2024-06-12T14:11:22Z

Ugh, sorry, pushed right before bed last night and didn't test enough :/

valentinewallace · 2024-06-12T14:48:39Z

LGTM, feel free to squash IMO.

Now that we are gearing up to support fully async monitor storage, we really need to fuzz monitor updates not completing before a reload, which we do here in the `chanmon_consistency` fuzzer. While there are more parts to async monitor updating that we need to fuzz, this at least gets us started by having basic async restart cases handled. In the future, we should extend this to make sure some basic properties (eg claim/balance consistency) remain true through `chanmon_consistency` runs.

When we have `ChannelMonitorUpdate`s which are completing both synchronously and asynchronously, we need to consider a channel as unblocked based on the `ChannelManager` monitor update queue, rather than by checking the `update_id`s. Consider the case where a channel is updated, leading to a `ChannelMonitorUpdate` which completes asynchronously. The update completes, but prior to the `ChannelManager` receiving the `MonitorEvent::Completed` it generates a further `ChannelMonitorUpdate`. This second update completes synchronously. As a result, when the `MonitorEvent` is processed, the event's `monitor_update_id` is the first update, but there are no updates queued and the channel should be free to return to be unblocked. Here we fix this by looking only at the `ChannelManager` update queue, rather than the update_id of the `MonitorEvent`. While we don't anticipate many users having both synchronous and asynchronous persists in the same application, there isn't much cost to supporting it, which we do here. Found by the chanmon_consistency target.

TheBlueMatt · 2024-06-12T15:32:48Z

Squashed without further changes.

TheBlueMatt · 2024-06-10T18:43:04Z

Now that we are gearing up to support fully async monitor storage, we really need to fuzz monitor updates not completing before a reload, which we do here in the chanmon_consistency fuzzer.

While there are more parts to async monitor updating that we need to fuzz, this at least gets us started by having basic async restart cases handled. In the future, we should extend this to make sure some basic properties (eg claim/balance consistency) remain true through chanmon_consistency runs.

codecov-commenter · 2024-06-10T21:08:29Z

Codecov Report

Attention: Patch coverage is 97.50000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 90.65%. Comparing base (1d0c6c6) to head (2a0c900).
Report is 15 commits behind head on main.

Files	Patch %	Lines
lightning/src/ln/chanmon_update_fail_tests.rs	97.46%	2 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #3113 +/- ##
==========================================
+ Coverage 89.84% 90.65% +0.80% 
==========================================
Files 119 119 Lines 97811 102825 +5014 Branches 97811 102825 +5014 ==========================================
+ Hits 87883 93217 +5334 + Misses 7364 7108 -256 + Partials 2564 2500 -64

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

tnull

Generally LGTM, just a few questions/comments.

tnull · 2024-06-11T10:52:28Z

+ &|v: &mut Vec<_>| if !v.is_empty() { Some(v.remove(0)) } else { None }),
+ 0xf1 =>
+ complete_monitor_update(&monitor_a, &chan_1_funding,
+ &|v: &mut Vec<_>| if v.len() > 1 { Some(v.remove(1)) } else { None }),


Not quite sure why we alternate between 0 and 1 here? Would we gain anything in terms of coverage by choosing randomly from 0..len?

We can't chose randomly because fuzzer results need to be deterministic based on the input. We could read another byte of fuzz input and use that, but we really want the fuzz input to be as dense as possible, so using a single bit for it seems sufficient. I'm not sure that we'd have any issues that can't be expressed through finishing (first, second, last), but could see some issues arising where we need to finish something in the middle that isnt first or last.

We can't chose randomly because fuzzer results need to be deterministic based on the input. We could read another byte of fuzz input and use that
Right, I imagined the latter.
but we really want the fuzz input to be as dense as possible, so using a single bit for it seems sufficient. I'm not sure that we'd have any issues that can't be expressed through finishing (first, second, last), but could see some issues arising where we need to finish something in the middle that isnt first or last.
Yeah, that's why I thought covering the entire Vec might be worth it, but maybe it's not too important.

TheBlueMatt · 2024-06-12T02:27:58Z

Addressed feedback.

tnull · 2024-06-12T08:57:44Z

Addressed feedback.

Unfortunately the new test now reliably fails:

thread 'ln::chanmon_update_fail_tests::test_sync_async_persist_doesnt_hang' panicked at 'explicit panic', lightning/src/ln/chanmon_update_fail_tests.rs:3410:14

TheBlueMatt · 2024-06-12T14:11:22Z

Ugh, sorry, pushed right before bed last night and didn't test enough :/

valentinewallace · 2024-06-12T14:48:39Z

LGTM, feel free to squash IMO.

Now that we are gearing up to support fully async monitor storage, we really need to fuzz monitor updates not completing before a reload, which we do here in the `chanmon_consistency` fuzzer. While there are more parts to async monitor updating that we need to fuzz, this at least gets us started by having basic async restart cases handled. In the future, we should extend this to make sure some basic properties (eg claim/balance consistency) remain true through `chanmon_consistency` runs.

When we have `ChannelMonitorUpdate`s which are completing both synchronously and asynchronously, we need to consider a channel as unblocked based on the `ChannelManager` monitor update queue, rather than by checking the `update_id`s. Consider the case where a channel is updated, leading to a `ChannelMonitorUpdate` which completes asynchronously. The update completes, but prior to the `ChannelManager` receiving the `MonitorEvent::Completed` it generates a further `ChannelMonitorUpdate`. This second update completes synchronously. As a result, when the `MonitorEvent` is processed, the event's `monitor_update_id` is the first update, but there are no updates queued and the channel should be free to return to be unblocked. Here we fix this by looking only at the `ChannelManager` update queue, rather than the update_id of the `MonitorEvent`. While we don't anticipate many users having both synchronous and asynchronous persists in the same application, there isn't much cost to supporting it, which we do here. Found by the chanmon_consistency target.

TheBlueMatt · 2024-06-12T15:32:48Z

Squashed without further changes.

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from fd0ecbd to 7446a79Compare June 10, 2024 21:01

TheBlueMatt mentioned this pull request Jun 10, 2024
rustfmt: Reformat the fuzz dir #3102
Merged

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch 2 times, most recently from b7a57bc to 61aef9bCompare June 10, 2024 21:46

tnull reviewed Jun 11, 2024
View reviewed changes

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 3a944d2 to c05e508Compare June 11, 2024 13:57

valentinewallace reviewed Jun 11, 2024
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs
Comment threadfuzz/src/chanmon_consistency.rs Outdated
Comment threadfuzz/src/chanmon_consistency.rs Outdated
Comment threadfuzz/src/chanmon_consistency.rs

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from c05e508 to 9d0c1a1Compare June 12, 2024 02:26

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 384d691 to 2a0c900Compare June 12, 2024 14:11

TheBlueMatt added 2 commits June 12, 2024 15:32

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 2a0c900 to 920d96eCompare June 12, 2024 15:32

valentinewallace approved these changes Jun 12, 2024
View reviewed changes

tnull approved these changes Jun 12, 2024
View reviewed changes

tnull merged commit 5e3056e into lightningdevkit:mainJun 12, 2024

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from fd0ecbd to 7446a79Compare June 10, 2024 21:01

TheBlueMatt mentioned this pull request Jun 10, 2024
rustfmt: Reformat the fuzz dir #3102
Merged

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch 2 times, most recently from b7a57bc to 61aef9bCompare June 10, 2024 21:46

tnull reviewed Jun 11, 2024
View reviewed changes

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 3a944d2 to c05e508Compare June 11, 2024 13:57

valentinewallace reviewed Jun 11, 2024
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs
Comment threadfuzz/src/chanmon_consistency.rs Outdated
Comment threadfuzz/src/chanmon_consistency.rs Outdated
Comment threadfuzz/src/chanmon_consistency.rs

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from c05e508 to 9d0c1a1Compare June 12, 2024 02:26

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 384d691 to 2a0c900Compare June 12, 2024 14:11

TheBlueMatt added 2 commits June 12, 2024 15:32

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 2a0c900 to 920d96eCompare June 12, 2024 15:32

valentinewallace approved these changes Jun 12, 2024
View reviewed changes

tnull approved these changes Jun 12, 2024
View reviewed changes

tnull merged commit 5e3056e into lightningdevkit:mainJun 12, 2024

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from fd0ecbd to 7446a79Compare June 10, 2024 21:01

TheBlueMatt mentioned this pull request Jun 10, 2024
rustfmt: Reformat the fuzz dir #3102
Merged

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch 2 times, most recently from b7a57bc to 61aef9bCompare June 10, 2024 21:46

tnull reviewed Jun 11, 2024
View reviewed changes

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 3a944d2 to c05e508Compare June 11, 2024 13:57

valentinewallace reviewed Jun 11, 2024
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs
Comment threadfuzz/src/chanmon_consistency.rs Outdated
Comment threadfuzz/src/chanmon_consistency.rs Outdated
Comment threadfuzz/src/chanmon_consistency.rs

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from c05e508 to 9d0c1a1Compare June 12, 2024 02:26

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 384d691 to 2a0c900Compare June 12, 2024 14:11

TheBlueMatt added 2 commits June 12, 2024 15:32

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 2a0c900 to 920d96eCompare June 12, 2024 15:32

valentinewallace approved these changes Jun 12, 2024
View reviewed changes

tnull approved these changes Jun 12, 2024
View reviewed changes

tnull merged commit 5e3056e into lightningdevkit:mainJun 12, 2024

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from fd0ecbd to 7446a79Compare June 10, 2024 21:01

TheBlueMatt mentioned this pull request Jun 10, 2024
rustfmt: Reformat the fuzz dir #3102
Merged

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch 2 times, most recently from b7a57bc to 61aef9bCompare June 10, 2024 21:46

tnull reviewed Jun 11, 2024
View reviewed changes

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 3a944d2 to c05e508Compare June 11, 2024 13:57

valentinewallace reviewed Jun 11, 2024
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs
Comment threadfuzz/src/chanmon_consistency.rs Outdated
Comment threadfuzz/src/chanmon_consistency.rs Outdated
Comment threadfuzz/src/chanmon_consistency.rs

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from c05e508 to 9d0c1a1Compare June 12, 2024 02:26

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 384d691 to 2a0c900Compare June 12, 2024 14:11

TheBlueMatt added 2 commits June 12, 2024 15:32

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 2a0c900 to 920d96eCompare June 12, 2024 15:32

valentinewallace approved these changes Jun 12, 2024
View reviewed changes

tnull approved these changes Jun 12, 2024
View reviewed changes

tnull merged commit 5e3056e into lightningdevkit:mainJun 12, 2024

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from fd0ecbd to 7446a79Compare June 10, 2024 21:01

TheBlueMatt mentioned this pull request Jun 10, 2024
rustfmt: Reformat the fuzz dir #3102
Merged

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch 2 times, most recently from b7a57bc to 61aef9bCompare June 10, 2024 21:46

tnull reviewed Jun 11, 2024
View reviewed changes

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 3a944d2 to c05e508Compare June 11, 2024 13:57

valentinewallace reviewed Jun 11, 2024
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs
Comment threadfuzz/src/chanmon_consistency.rs Outdated
Comment threadfuzz/src/chanmon_consistency.rs Outdated
Comment threadfuzz/src/chanmon_consistency.rs

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from c05e508 to 9d0c1a1Compare June 12, 2024 02:26

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 384d691 to 2a0c900Compare June 12, 2024 14:11

TheBlueMatt added 2 commits June 12, 2024 15:32

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 2a0c900 to 920d96eCompare June 12, 2024 15:32

valentinewallace approved these changes Jun 12, 2024
View reviewed changes

tnull approved these changes Jun 12, 2024
View reviewed changes

tnull merged commit 5e3056e into lightningdevkit:mainJun 12, 2024

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from fd0ecbd to 7446a79Compare June 10, 2024 21:01

TheBlueMatt mentioned this pull request Jun 10, 2024
rustfmt: Reformat the fuzz dir #3102
Merged

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch 2 times, most recently from b7a57bc to 61aef9bCompare June 10, 2024 21:46

tnull reviewed Jun 11, 2024
View reviewed changes

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 3a944d2 to c05e508Compare June 11, 2024 13:57

valentinewallace reviewed Jun 11, 2024
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs
Comment threadfuzz/src/chanmon_consistency.rs Outdated
Comment threadfuzz/src/chanmon_consistency.rs Outdated
Comment threadfuzz/src/chanmon_consistency.rs

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from c05e508 to 9d0c1a1Compare June 12, 2024 02:26

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 384d691 to 2a0c900Compare June 12, 2024 14:11

TheBlueMatt added 2 commits June 12, 2024 15:32

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 2a0c900 to 920d96eCompare June 12, 2024 15:32

valentinewallace approved these changes Jun 12, 2024
View reviewed changes

tnull approved these changes Jun 12, 2024
View reviewed changes

tnull merged commit 5e3056e into lightningdevkit:mainJun 12, 2024

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from fd0ecbd to 7446a79Compare June 10, 2024 21:01

TheBlueMatt mentioned this pull request Jun 10, 2024
rustfmt: Reformat the fuzz dir #3102
Merged

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch 2 times, most recently from b7a57bc to 61aef9bCompare June 10, 2024 21:46

tnull reviewed Jun 11, 2024
View reviewed changes

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 3a944d2 to c05e508Compare June 11, 2024 13:57

valentinewallace reviewed Jun 11, 2024
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs
Comment threadfuzz/src/chanmon_consistency.rs Outdated
Comment threadfuzz/src/chanmon_consistency.rs Outdated
Comment threadfuzz/src/chanmon_consistency.rs

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from c05e508 to 9d0c1a1Compare June 12, 2024 02:26

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 384d691 to 2a0c900Compare June 12, 2024 14:11

TheBlueMatt added 2 commits June 12, 2024 15:32

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 2a0c900 to 920d96eCompare June 12, 2024 15:32

valentinewallace approved these changes Jun 12, 2024
View reviewed changes

tnull approved these changes Jun 12, 2024
View reviewed changes

tnull merged commit 5e3056e into lightningdevkit:mainJun 12, 2024

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from fd0ecbd to 7446a79Compare June 10, 2024 21:01

TheBlueMatt mentioned this pull request Jun 10, 2024
rustfmt: Reformat the fuzz dir #3102
Merged

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch 2 times, most recently from b7a57bc to 61aef9bCompare June 10, 2024 21:46

tnull reviewed Jun 11, 2024
View reviewed changes

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 3a944d2 to c05e508Compare June 11, 2024 13:57

valentinewallace reviewed Jun 11, 2024
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs
Comment threadfuzz/src/chanmon_consistency.rs Outdated
Comment threadfuzz/src/chanmon_consistency.rs Outdated
Comment threadfuzz/src/chanmon_consistency.rs

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from c05e508 to 9d0c1a1Compare June 12, 2024 02:26

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 384d691 to 2a0c900Compare June 12, 2024 14:11

TheBlueMatt added 2 commits June 12, 2024 15:32

TheBlueMatt force-pushed the 2024-04-async-monitor-fuzz branch from 2a0c900 to 920d96eCompare June 12, 2024 15:32

valentinewallace approved these changes Jun 12, 2024
View reviewed changes

tnull approved these changes Jun 12, 2024
View reviewed changes

tnull merged commit 5e3056e into lightningdevkit:mainJun 12, 2024

Uh oh!

Conversation

TheBlueMatt commented Jun 10, 2024

Uh oh!

codecov-commenter commented Jun 10, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

TheBlueMatt commented Jun 12, 2024

Uh oh!

tnull commented Jun 12, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TheBlueMatt commented Jun 12, 2024

Uh oh!

valentinewallace commented Jun 12, 2024

Uh oh!

TheBlueMatt commented Jun 12, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

TheBlueMatt commented Jun 10, 2024

Uh oh!

codecov-commenter commented Jun 10, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

TheBlueMatt commented Jun 12, 2024

Uh oh!

tnull commented Jun 12, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TheBlueMatt commented Jun 12, 2024

Uh oh!

valentinewallace commented Jun 12, 2024

Uh oh!

TheBlueMatt commented Jun 12, 2024

Uh oh!

Reviewers

Assignees

codecov-commenter commented Jun 10, 2024•
edited
Loading

tnull commented Jun 12, 2024•
edited
Loading

codecov-commenter commented Jun 10, 2024•
edited
Loading

tnull commented Jun 12, 2024•
edited
Loading

codecov-commenter commented Jun 10, 2024•
edited
Loading

tnull commented Jun 12, 2024•
edited
Loading