Skip to content

Conversation

@arik-so
Copy link
Contributor

@arik-so arik-so commented Aug 27, 2024

Fixes #3228.

@TheBlueMatt TheBlueMatt added this to the 0.0.124 milestone Aug 27, 2024
@codecov
Copy link

codecov bot commented Aug 27, 2024

Codecov Report

Attention: Patch coverage is 71.42857% with 8 lines in your changes missing coverage. Please review.

Project coverage is 90.69%. Comparing base (0d7ae86) to head (47c8aa5).
Report is 44 commits behind head on main.

Files with missing lines Patch % Lines
lightning/src/util/persist.rs 71.42% 7 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3276      +/-   ##
==========================================
+ Coverage   89.82%   90.69%   +0.86%     
==========================================
  Files         125      126       +1     
  Lines      102830   110223    +7393     
  Branches   102830   110223    +7393     
==========================================
+ Hits        92368    99965    +7597     
+ Misses       7752     7671      -81     
+ Partials     2710     2587     -123     

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

@arik-so arik-so marked this pull request as ready for review August 28, 2024 05:06
@TheBlueMatt
Copy link
Collaborator

LGTM, though could split it into more than one commit.

@arik-so
Copy link
Contributor Author

arik-so commented Aug 28, 2024

Technically both commits are refactors that work in isolation, so you could de-fixup the other one, unless you envision a different splt. But on the other hand, it's a ±50-line-change.

@TheBlueMatt
Copy link
Collaborator

Probably removing the parameters from the existing functions should be a separate commit because it does something that is logically quite different and the change itself is an important bugfix.

@TheBlueMatt
Copy link
Collaborator

Feel free to squash, change commits, and please write commit messages.

@arik-so arik-so force-pushed the arik/2024/08/apply_monitor_updates_on_archive branch from e0560ac to 7162cd3 Compare August 28, 2024 16:51
@arik-so arik-so requested a review from TheBlueMatt August 28, 2024 17:31
TheBlueMatt
TheBlueMatt previously approved these changes Aug 28, 2024
`MonitorUpdatingPersister` does not currently correctly archive
monitors because it neglects any unapplied updates. In order to start
applying these updates, the archiving methods will require access to
instances of `BroadcasterInterface` and `FeeEstimator`.

This commit requires that the `MonitorUpdatingPersister` be
instantiated with those instances, obviating the need for passing
them around, and laying the foundation for the following commit.
Previously, `MonitorUpdatingPersister` was disregarding any unapplied
monitor updates when archiving them. This commit ensures that upon
reading monitors, their corresponding updates are also read and
applied prior to archiving.
@arik-so arik-so force-pushed the arik/2024/08/apply_monitor_updates_on_archive branch from 7162cd3 to 47c8aa5 Compare August 28, 2024 19:19
let monitor = match self.read_monitor(&monitor_name) {
let monitor_key = monitor_name.as_str().to_string();
let monitor = match self.read_channel_monitor_with_updates(monitor_key) {
Ok((_block_hash, monitor)) => monitor,
Copy link
Contributor

Choose a reason for hiding this comment

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

Pre-existing, but I think the read_monitor method could use a rename and maybe some docs since it basically reads an old monitor, which seems worth a call-out. No need to do it in this PR though

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point. Separately, there's also the issue of applying monitor updates requiring a fee estimator and a broadcaster in the first place, which should be avoidable. I'll create issues for both.

let monitor_name = MonitorName::from(funding_txo);
let monitor = match self.read_monitor(&monitor_name) {
let monitor_key = monitor_name.as_str().to_string();
let monitor = match self.read_channel_monitor_with_updates(monitor_key) {
Copy link
Contributor

Choose a reason for hiding this comment

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

FWIW, I'm not sure this bug is reachable at the moment because I think LDK will persist the full monitor on each block connection, and we don't archive until ~4k blocks have passed post-channel close. Still seems like a reasonable fix though in case things change.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, that caveat is addressed in the issue this is fixing. I think it primarily affects mobile clients.

@TheBlueMatt TheBlueMatt merged commit a978076 into lightningdevkit:main Aug 28, 2024
G8XSU added a commit that referenced this pull request Oct 15, 2024
Document monitor archival idempotency requirement (#3276 followup)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

MonitorUpdatingPersister apparently reads only no-update monitors when archiving

4 participants