Commit f59557f
committed
Correctly track reloaded update_id in
In the `chanmon_consistency` fuzzer, when reloading a node, we
take a pending monitor update (or the latest persisted one) and put
it in `persisted_monitor` as it is implicitly the latest persisted
monitor on restart. However, we failed to update
`persisted_monitor_id`. As a result, we may restart and write the
loaded monitor to `persisted_monitor` (eg at ID 2) but have a
later `persisted_monitor_id` (eg ID 3). Then, when we complete
the monitor update for the `persisted_monitor_id` (here, 3) we will
think that its not a new update and neglect to update
`persisted_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 with `persisted_monitor` on reload.chanmon_consistency fuzzer1 parent 2efb009 commit f59557f
1 file changed
+12
-7
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
171 | 171 | | |
172 | 172 | | |
173 | 173 | | |
174 | | - | |
| 174 | + | |
| 175 | + | |
| 176 | + | |
| 177 | + | |
| 178 | + | |
175 | 179 | | |
176 | 180 | | |
177 | 181 | | |
| |||
726 | 730 | | |
727 | 731 | | |
728 | 732 | | |
729 | | - | |
| 733 | + | |
730 | 734 | | |
731 | 735 | | |
732 | | - | |
| 736 | + | |
733 | 737 | | |
734 | 738 | | |
735 | | - | |
736 | | - | |
| 739 | + | |
| 740 | + | |
737 | 741 | | |
738 | 742 | | |
739 | | - | |
740 | | - | |
| 743 | + | |
| 744 | + | |
741 | 745 | | |
742 | 746 | | |
743 | 747 | | |
| |||
750 | 754 | | |
751 | 755 | | |
752 | 756 | | |
| 757 | + | |
753 | 758 | | |
754 | 759 | | |
755 | 760 | | |
| |||
0 commit comments