Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 480
Replace dual-sync-async persistence panic with Watch contract#4436
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Uh oh!
There was an error while loading. Please reload this page.
Changes from all commits
File filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -233,11 +233,10 @@ pub enum ChannelMonitorUpdateStatus { | ||
| /// This includes performing any `fsync()` calls required to ensure the update is guaranteed to | ||
| /// be available on restart even if the application crashes. | ||
| /// | ||
| /// If you return this variant, you cannot later return [`InProgress`] from the same instance of | ||
| /// [`Persist`]/[`Watch`] without first restarting. | ||
| /// You cannot switch from [`InProgress`] to this variant for the same channel without first | ||
| /// restarting. However, switching from this variant to [`InProgress`] is always allowed. | ||
TheBlueMatt marked this conversation as resolved.
Uh oh!There was an error while loading. Please reload this page. | ||
| /// | ||
TheBlueMatt marked this conversation as resolved.
Uh oh!There was an error while loading. Please reload this page. | ||
| /// [`InProgress`]: ChannelMonitorUpdateStatus::InProgress | ||
| /// [`Persist`]: chainmonitor::Persist | ||
| Completed, | ||
| /// Indicates that the update will happen asynchronously in the background or that a transient | ||
| /// failure occurred which is being retried in the background and will eventually complete. | ||
| @@ -263,12 +262,7 @@ pub enum ChannelMonitorUpdateStatus { | ||
| /// reliable, this feature is considered beta, and a handful of edge-cases remain. Until the | ||
| /// remaining cases are fixed, in rare cases, *using this feature may lead to funds loss*. | ||
| /// | ||
| /// If you return this variant, you cannot later return [`Completed`] from the same instance of | ||
| /// [`Persist`]/[`Watch`] without first restarting. | ||
| /// | ||
| /// [`InProgress`]: ChannelMonitorUpdateStatus::InProgress | ||
| /// [`Completed`]: ChannelMonitorUpdateStatus::Completed | ||
| /// [`Persist`]: chainmonitor::Persist | ||
| InProgress, | ||
| /// Indicates that an update has failed and will not complete at any point in the future. | ||
| /// | ||
| @@ -328,6 +322,8 @@ pub trait Watch<ChannelSigner: EcdsaChannelSigner> { | ||
| /// cannot be retried, the node should shut down immediately after returning | ||
| /// [`ChannelMonitorUpdateStatus::UnrecoverableError`], see its documentation for more info. | ||
| /// | ||
| /// See [`ChannelMonitorUpdateStatus`] for requirements on when each variant may be returned. | ||
| /// | ||
| /// [`ChannelManager`]: crate::ln::channelmanager::ChannelManager | ||
| fn update_channel( | ||
| &self, channel_id: ChannelId, update: &ChannelMonitorUpdate, | ||
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reordering here affects all async persist completions, not just the new deferred post-close ones. Previously,
pending_monitor_events(which includesCompletedevents fromchannel_monitor_updated/ async persist callbacks) was drained before per-monitor events. Now it's drained after.This means if an async persist completion and a force-close
MonitorEvent(e.g.,CommitmentTxConfirmed) are both pending in the samerelease_pending_monitor_eventscall, the force-close is now processed first byChannelManager. Previously, the persist completion would have been processed first, potentially unfreezing the channel and allowing queued messages to flow before the force-close.This is likely the intended behavior for the deferred-completion case, but it's a broader behavioral change that also affects the normal async-persist path. Worth documenting in the commit message or a code comment that this ordering change is intentional and applies to all
channel_monitor_updatedcompletions.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is intended behavior indeed.