Hold in-flight monitor updates until background event processing #4377
+157
−20
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.
We previously assumed background events would eventually be processed prior to another
ChannelManagerwrite, so we would immediately remove all in-flight monitor updates that completed since the lastChannelManagerserialization. This isn't always the case, so we now keep them all around until we're ready to handle them, i.e., whenprocess_background_eventsis called.This was discovered while fuzzing
chanmon_consistency_targeton the main branch with some changes that allow it to connect blocks. It was triggered by reloading theChannelManagerafter a monitor update completion for an outgoing HTLC, callingChannelManager::best_block_updated, and reloading theChannelManageronce again. A test is included that provides a minimal reproduction of this case.