Correctly track reloaded update_id in chanmon_consistency
fuzzer
#4145
+12
−7
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.
In the
chanmon_consistency
fuzzer, when reloading a node, we take a pending monitor update (or the latest persisted one) and put it inpersisted_monitor
as it is implicitly the latest persisted monitor on restart. However, we failed to updatepersisted_monitor_id
. As a result, we may restart and write the loaded monitor topersisted_monitor
(eg at ID 2) but have a laterpersisted_monitor_id
(eg ID 3). Then, when we complete the monitor update for thepersisted_monitor_id
(here, 3) we will think that its not a new update and neglect to updatepersisted_monitor
/persisted_monitor_id
. As a result, later updates (e.g. ID 4) will fail as we're trying to apply them to the original persisted monitor (at ID 2).The fix is simply to ensure
persisted_monitor_id
is always updated in lock-step withpersisted_monitor
on reload.