Don't drop ChannelMonitor Events until they're processed#2369

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.

Sign up for GitHub

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

Merged
wpaulino merged 1 commit into from
Jul 10, 2023
Merged

Don't drop ChannelMonitor Events until they're processed #2369

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 8 additions & 11 deletions lightning/src/chain/chainmonitor.rs
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -520,12 +520,13 @@ where C::Target: chain::Filter,
pub async fn process_pending_events_async<Future: core::future::Future, H: Fn(Event) -> Future>(
&self, handler: H
) {
let mut pending_events = Vec::new();
for monitor_state in self.monitors.read().unwrap().values() {
pending_events.append(&mut monitor_state.monitor.get_and_clear_pending_events());
}
for event in pending_events {
handler(event).await;
// Sadly we can't hold the monitors read lock through an async call. Thus we have to do a
// crazy dance to process a monitor's events then only remove them once we've done so.
let mons_to_process = self.monitors.read().unwrap().keys().cloned().collect::<Vec<_>>();
for funding_txo in mons_to_process {
let mut ev;
super::channelmonitor::process_events_body!(
self.monitors.read().unwrap().get(&funding_txo).map(|m| &m.monitor), ev, handler(ev).await);

@alecchendevalecchendevJul 6, 2023

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Will this first argument ever be None?

@TheBlueMattTheBlueMattJul 7, 2023

Copy link
Copy Markdown
CollaboratorAuthor

Choose a reason for hiding this comment

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

Currently I don't think so, but in the future we probably want to support removing monitors after they're done with all their processing (and probably will do so automatically). Thus, we should handle the case where the monitor has dissapeared on us (we don't hold a lock through the loop anyway, so its good practice to not rely on any assumptions about the underlying data changing).

}
}

Expand DownExpand Up@@ -796,12 +797,8 @@ impl<ChannelSigner: WriteableEcdsaChannelSigner, C: Deref, T: Deref, F: Deref, L
/// [`SpendableOutputs`]: events::Event::SpendableOutputs
/// [`BumpTransaction`]: events::Event::BumpTransaction
fn process_pending_events<H: Deref>(&self, handler: H) where H::Target: EventHandler {
let mut pending_events = Vec::new();
for monitor_state in self.monitors.read().unwrap().values() {
pending_events.append(&mut monitor_state.monitor.get_and_clear_pending_events());
}
for event in pending_events {
handler.handle_event(event);
monitor_state.monitor.process_pending_events(&handler);
}
}
}
Expand Down
100 changes: 81 additions & 19 deletions lightning/src/chain/channelmonitor.rs
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -49,7 +49,7 @@ use crate::chain::Filter;
use crate::util::logger::Logger;
use crate::util::ser::{Readable, ReadableArgs, RequiredWrapper, MaybeReadable, UpgradableRequired, Writer, Writeable, U48};
use crate::util::byte_utils;
use crate::events::Event;
use crate::events::{Event, EventHandler};
use crate::events::bump_transaction::{AnchorDescriptor, HTLCDescriptor, BumpTransactionEvent};

use crate::prelude::*;
Expand DownExpand Up@@ -738,11 +738,6 @@ impl Readable for IrrevocablyResolvedHTLC {
/// You MUST ensure that no ChannelMonitors for a given channel anywhere contain out-of-date
/// information and are actively monitoring the chain.
///
/// Pending Events or updated HTLCs which have not yet been read out by
/// get_and_clear_pending_monitor_events or get_and_clear_pending_events are serialized to disk and
/// reloaded at deserialize-time. Thus, you must ensure that, when handling events, all events
/// gotten are fully handled before re-serializing the new state.
///
/// Note that the deserializer is only implemented for (BlockHash, ChannelMonitor), which
/// tells you the last block hash which was block_connect()ed. You MUST rescan any blocks along
/// the "reorg path" (ie disconnecting blocks until you find a common ancestor from both the
Expand All@@ -752,7 +747,7 @@ pub struct ChannelMonitor<Signer: WriteableEcdsaChannelSigner> {
#[cfg(test)]
pub(crate) inner: Mutex<ChannelMonitorImpl<Signer>>,
#[cfg(not(test))]
inner: Mutex<ChannelMonitorImpl<Signer>>,
pub(super) inner: Mutex<ChannelMonitorImpl<Signer>>,
}

#[derive(PartialEq)]
Expand DownExpand Up@@ -829,7 +824,8 @@ pub(crate) struct ChannelMonitorImpl<Signer: WriteableEcdsaChannelSigner> {
// we further MUST NOT generate events during block/transaction-disconnection.
pending_monitor_events: Vec<MonitorEvent>,

pending_events: Vec<Event>,
pub(super) pending_events: Vec<Event>,
pub(super) is_processing_pending_events: bool,

// Used to track on-chain events (i.e., transactions part of channels confirmed on chain) on
// which to take actions once they reach enough confirmations. Each entry includes the
Expand DownExpand Up@@ -1088,6 +1084,42 @@ impl<Signer: WriteableEcdsaChannelSigner> Writeable for ChannelMonitorImpl<Signe
}
}

macro_rules! _process_events_body {
($self_opt: expr, $event_to_handle: expr, $handle_event: expr) => {
loop {
let (pending_events, repeated_events);
if let Some(us) = $self_opt {
let mut inner = us.inner.lock().unwrap();
if inner.is_processing_pending_events {
break;
}
inner.is_processing_pending_events = true;

pending_events = inner.pending_events.clone();
repeated_events = inner.get_repeated_events();
} else { break; }
let num_events = pending_events.len();

for event in pending_events.into_iter().chain(repeated_events.into_iter()) {
$event_to_handle = event;
$handle_event;
Comment thread
wpaulino marked this conversation as resolved.
}

if let Some(us) = $self_opt {
let mut inner = us.inner.lock().unwrap();
inner.pending_events.drain(..num_events);
inner.is_processing_pending_events = false;
if !inner.pending_events.is_empty() {
// If there's more events to process, go ahead and do so.
continue;
}
}
break;
Comment thread
wpaulino marked this conversation as resolved.
Comment thread
TheBlueMatt marked this conversation as resolved.
}
}
}
pub(super) use _process_events_body as process_events_body;

impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
/// For lockorder enforcement purposes, we need to have a single site which constructs the
/// `inner` mutex, otherwise cases where we lock two monitors at the same time (eg in our
Expand DownExpand Up@@ -1179,6 +1211,7 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
payment_preimages: HashMap::new(),
pending_monitor_events: Vec::new(),
pending_events: Vec::new(),
is_processing_pending_events: false,

onchain_events_awaiting_threshold_conf: Vec::new(),
outputs_to_watch,
Expand DownExpand Up@@ -1306,16 +1339,41 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
self.inner.lock().unwrap().get_and_clear_pending_monitor_events()
}

/// Gets the list of pending events which were generated by previous actions, clearing the list
/// in the process.
/// Processes [`SpendableOutputs`] events produced from each [`ChannelMonitor`] upon maturity.
///
/// For channels featuring anchor outputs, this method will also process [`BumpTransaction`]
/// events produced from each [`ChannelMonitor`] while there is a balance to claim onchain
/// within each channel. As the confirmation of a commitment transaction may be critical to the
/// safety of funds, we recommend invoking this every 30 seconds, or lower if running in an
/// environment with spotty connections, like on mobile.
///
/// This is called by the [`EventsProvider::process_pending_events`] implementation for
/// [`ChainMonitor`].
/// An [`EventHandler`] may safely call back to the provider, though this shouldn't be needed in
/// order to handle these events.
///
/// [`SpendableOutputs`]: crate::events::Event::SpendableOutputs
/// [`BumpTransaction`]: crate::events::Event::BumpTransaction
pub fn process_pending_events<H: Deref>(&self, handler: &H) where H::Target: EventHandler {
let mut ev;
process_events_body!(Some(self), ev, handler.handle_event(ev));
}

/// Processes any events asynchronously.
///
/// [`EventsProvider::process_pending_events`]: crate::events::EventsProvider::process_pending_events
/// [`ChainMonitor`]: crate::chain::chainmonitor::ChainMonitor
/// See [`Self::process_pending_events`] for more information.
pub async fn process_pending_events_async<Future: core::future::Future, H: Fn(Event) -> Future>(
&self, handler: &H
) {
let mut ev;
process_events_body!(Some(self), ev, { handler(ev).await });
}

#[cfg(test)]
pub fn get_and_clear_pending_events(&self) -> Vec<Event> {
Comment thread
TheBlueMatt marked this conversation as resolved.
self.inner.lock().unwrap().get_and_clear_pending_events()
let mut ret = Vec::new();
let mut lck = self.inner.lock().unwrap();
mem::swap(&mut ret, &mut lck.pending_events);
ret.append(&mut lck.get_repeated_events());
ret
}

pub(crate) fn get_min_seen_secret(&self) -> u64 {
Expand DownExpand Up@@ -2531,10 +2589,13 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitorImpl<Signer> {
ret
}

pub fn get_and_clear_pending_events(&mut self) -> Vec<Event> {
let mut ret = Vec::new();
mem::swap(&mut ret, &mut self.pending_events);
Comment thread
TheBlueMatt marked this conversation as resolved.
for (claim_id, claim_event) in self.onchain_tx_handler.get_and_clear_pending_claim_events().drain(..) {
/// Gets the set of events that are repeated regularly (e.g. those which RBF bump
/// transactions). We're okay if we lose these on restart as they'll be regenerated for us at
/// some regular interval via [`ChannelMonitor::rebroadcast_pending_claims`].
pub(super) fn get_repeated_events(&mut self) -> Vec<Event> {
let pending_claim_events = self.onchain_tx_handler.get_and_clear_pending_claim_events();
let mut ret = Vec::with_capacity(pending_claim_events.len());
for (claim_id, claim_event) in pending_claim_events {
match claim_event {
ClaimEvent::BumpCommitment {
package_target_feerate_sat_per_1000_weight, commitment_tx, anchor_output_idx,
Expand DownExpand Up@@ -4096,6 +4157,7 @@ impl<'a, 'b, ES: EntropySource, SP: SignerProvider> ReadableArgs<(&'a ES, &'b SP
payment_preimages,
pending_monitor_events: pending_monitor_events.unwrap(),
pending_events,
is_processing_pending_events: false,

onchain_events_awaiting_threshold_conf,
outputs_to_watch,
Expand Down
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
Don't drop ChannelMonitor Events until they're processed#2369

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.

 Sign up for GitHub

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

 Merged

wpaulino
merged 1 commit into

from

Jul 10, 2023
 Merged


Don't drop ChannelMonitor Events until they're processed
#2369
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


1 commit


Select commit


File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


19 changes: 8 additions & 11 deletions
lightning/src/chain/chainmonitor.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -520,12 +520,13 @@ where C::Target: chain::Filter,
	pub async fn process_pending_events_async<Future: core::future::Future, H: Fn(Event) -> Future>(
 &self, handler: H
	) {
 let mut pending_events = Vec::new();
 for monitor_state in self.monitors.read().unwrap().values() {
 pending_events.append(&mut monitor_state.monitor.get_and_clear_pending_events());
 }
 for event in pending_events {
 handler(event).await;
 // Sadly we can't hold the monitors read lock through an async call. Thus we have to do a
 // crazy dance to process a monitor's events then only remove them once we've done so.
 let mons_to_process = self.monitors.read().unwrap().keys().cloned().collect::<Vec<_>>();
 for funding_txo in mons_to_process {
 let mut ev;
 super::channelmonitor::process_events_body!(
 self.monitors.read().unwrap().get(&funding_txo).map(|m| &m.monitor), ev, handler(ev).await);
@alecchendevalecchendevJul 6, 2023

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

Will this first argument ever be None?
@TheBlueMattTheBlueMattJul 7, 2023

Copy link


Copy Markdown

CollaboratorAuthor
Choose a reason for hiding this comment

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

Currently I don't think so, but in the future we probably want to support removing monitors after they're done with all their processing (and probably will do so automatically). Thus, we should handle the case where the monitor has dissapeared on us (we don't hold a lock through the loop anyway, so its good practice to not rely on any assumptions about the underlying data changing).
 }
	}

Expand DownExpand Up@@ -796,12 +797,8 @@ impl<ChannelSigner: WriteableEcdsaChannelSigner, C: Deref, T: Deref, F: Deref, L
	/// [`SpendableOutputs`]: events::Event::SpendableOutputs
	/// [`BumpTransaction`]: events::Event::BumpTransaction
	fn process_pending_events<H: Deref>(&self, handler: H) where H::Target: EventHandler {
 let mut pending_events = Vec::new();
 for monitor_state in self.monitors.read().unwrap().values() {
 pending_events.append(&mut monitor_state.monitor.get_and_clear_pending_events());
 }
 for event in pending_events {
 handler.handle_event(event);
 monitor_state.monitor.process_pending_events(&handler);
 }
	}
}
Expand Down

100 changes: 81 additions & 19 deletions
lightning/src/chain/channelmonitor.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -49,7 +49,7 @@ use crate::chain::Filter;
use crate::util::logger::Logger;
use crate::util::ser::{Readable, ReadableArgs, RequiredWrapper, MaybeReadable, UpgradableRequired, Writer, Writeable, U48};
use crate::util::byte_utils;
use crate::events::Event;
use crate::events::{Event, EventHandler};
use crate::events::bump_transaction::{AnchorDescriptor, HTLCDescriptor, BumpTransactionEvent};

use crate::prelude::*;
Expand DownExpand Up@@ -738,11 +738,6 @@ impl Readable for IrrevocablyResolvedHTLC {
/// You MUST ensure that no ChannelMonitors for a given channel anywhere contain out-of-date
/// information and are actively monitoring the chain.
///
/// Pending Events or updated HTLCs which have not yet been read out by
/// get_and_clear_pending_monitor_events or get_and_clear_pending_events are serialized to disk and
/// reloaded at deserialize-time. Thus, you must ensure that, when handling events, all events
/// gotten are fully handled before re-serializing the new state.
///
/// Note that the deserializer is only implemented for (BlockHash, ChannelMonitor), which
/// tells you the last block hash which was block_connect()ed. You MUST rescan any blocks along
/// the "reorg path" (ie disconnecting blocks until you find a common ancestor from both the
Expand All@@ -752,7 +747,7 @@ pub struct ChannelMonitor<Signer: WriteableEcdsaChannelSigner> {
	#[cfg(test)]
	pub(crate) inner: Mutex<ChannelMonitorImpl<Signer>>,
	#[cfg(not(test))]
	inner: Mutex<ChannelMonitorImpl<Signer>>,
pub(super) inner: Mutex<ChannelMonitorImpl<Signer>>,
}

#[derive(PartialEq)]
Expand DownExpand Up@@ -829,7 +824,8 @@ pub(crate) struct ChannelMonitorImpl<Signer: WriteableEcdsaChannelSigner> {
	// we further MUST NOT generate events during block/transaction-disconnection.
	pending_monitor_events: Vec<MonitorEvent>,

	pending_events: Vec<Event>,
	pub(super) pending_events: Vec<Event>,
	pub(super) is_processing_pending_events: bool,

	// Used to track on-chain events (i.e., transactions part of channels confirmed on chain) on
	// which to take actions once they reach enough confirmations. Each entry includes the
Expand DownExpand Up@@ -1088,6 +1084,42 @@ impl<Signer: WriteableEcdsaChannelSigner> Writeable for ChannelMonitorImpl<Signe
	}
}

macro_rules! _process_events_body {
	($self_opt: expr, $event_to_handle: expr, $handle_event: expr) => {
 loop {
 let (pending_events, repeated_events);
 if let Some(us) = $self_opt {
 let mut inner = us.inner.lock().unwrap();
 if inner.is_processing_pending_events {
 break;
 }
 inner.is_processing_pending_events = true;

 pending_events = inner.pending_events.clone();
 repeated_events = inner.get_repeated_events();
 } else { break; }
 let num_events = pending_events.len();

 for event in pending_events.into_iter().chain(repeated_events.into_iter()) {
 $event_to_handle = event;
 $handle_event;
Comment thread
wpaulino marked this conversation as resolved.

 }

 if let Some(us) = $self_opt {
 let mut inner = us.inner.lock().unwrap();
 inner.pending_events.drain(..num_events);
 inner.is_processing_pending_events = false;
 if !inner.pending_events.is_empty() {
 // If there's more events to process, go ahead and do so.
 continue;
 }
 }
 break;
Comment thread
wpaulino marked this conversation as resolved.

Comment thread
TheBlueMatt marked this conversation as resolved.

 }
	}
}
pub(super) use _process_events_body as process_events_body;

impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
	/// For lockorder enforcement purposes, we need to have a single site which constructs the
	/// `inner` mutex, otherwise cases where we lock two monitors at the same time (eg in our
Expand DownExpand Up@@ -1179,6 +1211,7 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
 payment_preimages: HashMap::new(),
 pending_monitor_events: Vec::new(),
 pending_events: Vec::new(),
 is_processing_pending_events: false,

 onchain_events_awaiting_threshold_conf: Vec::new(),
 outputs_to_watch,
Expand DownExpand Up@@ -1306,16 +1339,41 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
 self.inner.lock().unwrap().get_and_clear_pending_monitor_events()
	}

	/// Gets the list of pending events which were generated by previous actions, clearing the list
	/// in the process.
	/// Processes [`SpendableOutputs`] events produced from each [`ChannelMonitor`] upon maturity.
	///
	/// For channels featuring anchor outputs, this method will also process [`BumpTransaction`]
	/// events produced from each [`ChannelMonitor`] while there is a balance to claim onchain
	/// within each channel. As the confirmation of a commitment transaction may be critical to the
	/// safety of funds, we recommend invoking this every 30 seconds, or lower if running in an
	/// environment with spotty connections, like on mobile.
	///
	/// This is called by the [`EventsProvider::process_pending_events`] implementation for
	/// [`ChainMonitor`].
	/// An [`EventHandler`] may safely call back to the provider, though this shouldn't be needed in
	/// order to handle these events.
	///
	/// [`SpendableOutputs`]: crate::events::Event::SpendableOutputs
	/// [`BumpTransaction`]: crate::events::Event::BumpTransaction
	pub fn process_pending_events<H: Deref>(&self, handler: &H) where H::Target: EventHandler {
 let mut ev;
 process_events_body!(Some(self), ev, handler.handle_event(ev));
	}

	/// Processes any events asynchronously.
	///
	/// [`EventsProvider::process_pending_events`]: crate::events::EventsProvider::process_pending_events
	/// [`ChainMonitor`]: crate::chain::chainmonitor::ChainMonitor
	/// See [`Self::process_pending_events`] for more information.
	pub async fn process_pending_events_async<Future: core::future::Future, H: Fn(Event) -> Future>(
 &self, handler: &H
	) {
 let mut ev;
 process_events_body!(Some(self), ev, { handler(ev).await });
	}

	#[cfg(test)]
	pub fn get_and_clear_pending_events(&self) -> Vec<Event> {
Comment thread
TheBlueMatt marked this conversation as resolved.

 self.inner.lock().unwrap().get_and_clear_pending_events()
 let mut ret = Vec::new();
 let mut lck = self.inner.lock().unwrap();
 mem::swap(&mut ret, &mut lck.pending_events);
 ret.append(&mut lck.get_repeated_events());
 ret
	}

	pub(crate) fn get_min_seen_secret(&self) -> u64 {
Expand DownExpand Up@@ -2531,10 +2589,13 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitorImpl<Signer> {
 ret
	}

	pub fn get_and_clear_pending_events(&mut self) -> Vec<Event> {
 let mut ret = Vec::new();
 mem::swap(&mut ret, &mut self.pending_events);
Comment thread
TheBlueMatt marked this conversation as resolved.

 for (claim_id, claim_event) in self.onchain_tx_handler.get_and_clear_pending_claim_events().drain(..) {
	/// Gets the set of events that are repeated regularly (e.g. those which RBF bump
	/// transactions). We're okay if we lose these on restart as they'll be regenerated for us at
	/// some regular interval via [`ChannelMonitor::rebroadcast_pending_claims`].
	pub(super) fn get_repeated_events(&mut self) -> Vec<Event> {
 let pending_claim_events = self.onchain_tx_handler.get_and_clear_pending_claim_events();
 let mut ret = Vec::with_capacity(pending_claim_events.len());
 for (claim_id, claim_event) in pending_claim_events {
 match claim_event {
 ClaimEvent::BumpCommitment {
 package_target_feerate_sat_per_1000_weight, commitment_tx, anchor_output_idx,
Expand DownExpand Up@@ -4096,6 +4157,7 @@ impl<'a, 'b, ES: EntropySource, SP: SignerProvider> ReadableArgs<(&'a ES, &'b SP
 payment_preimages,
 pending_monitor_events: pending_monitor_events.unwrap(),
 pending_events,
 is_processing_pending_events: false,

 onchain_events_awaiting_threshold_conf,
 outputs_to_watch,
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Don't drop ChannelMonitor Events until they're processed#2369

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.

 Sign up for GitHub

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

 Merged

wpaulino
merged 1 commit into

from

Jul 10, 2023
 Merged


Don't drop ChannelMonitor Events until they're processed
#2369
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


1 commit


Select commit


File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


19 changes: 8 additions & 11 deletions
lightning/src/chain/chainmonitor.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -520,12 +520,13 @@ where C::Target: chain::Filter,
	pub async fn process_pending_events_async<Future: core::future::Future, H: Fn(Event) -> Future>(
 &self, handler: H
	) {
 let mut pending_events = Vec::new();
 for monitor_state in self.monitors.read().unwrap().values() {
 pending_events.append(&mut monitor_state.monitor.get_and_clear_pending_events());
 }
 for event in pending_events {
 handler(event).await;
 // Sadly we can't hold the monitors read lock through an async call. Thus we have to do a
 // crazy dance to process a monitor's events then only remove them once we've done so.
 let mons_to_process = self.monitors.read().unwrap().keys().cloned().collect::<Vec<_>>();
 for funding_txo in mons_to_process {
 let mut ev;
 super::channelmonitor::process_events_body!(
 self.monitors.read().unwrap().get(&funding_txo).map(|m| &m.monitor), ev, handler(ev).await);
@alecchendevalecchendevJul 6, 2023

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

Will this first argument ever be None?
@TheBlueMattTheBlueMattJul 7, 2023

Copy link


Copy Markdown

CollaboratorAuthor
Choose a reason for hiding this comment

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

Currently I don't think so, but in the future we probably want to support removing monitors after they're done with all their processing (and probably will do so automatically). Thus, we should handle the case where the monitor has dissapeared on us (we don't hold a lock through the loop anyway, so its good practice to not rely on any assumptions about the underlying data changing).
 }
	}

Expand DownExpand Up@@ -796,12 +797,8 @@ impl<ChannelSigner: WriteableEcdsaChannelSigner, C: Deref, T: Deref, F: Deref, L
	/// [`SpendableOutputs`]: events::Event::SpendableOutputs
	/// [`BumpTransaction`]: events::Event::BumpTransaction
	fn process_pending_events<H: Deref>(&self, handler: H) where H::Target: EventHandler {
 let mut pending_events = Vec::new();
 for monitor_state in self.monitors.read().unwrap().values() {
 pending_events.append(&mut monitor_state.monitor.get_and_clear_pending_events());
 }
 for event in pending_events {
 handler.handle_event(event);
 monitor_state.monitor.process_pending_events(&handler);
 }
	}
}
Expand Down

100 changes: 81 additions & 19 deletions
lightning/src/chain/channelmonitor.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -49,7 +49,7 @@ use crate::chain::Filter;
use crate::util::logger::Logger;
use crate::util::ser::{Readable, ReadableArgs, RequiredWrapper, MaybeReadable, UpgradableRequired, Writer, Writeable, U48};
use crate::util::byte_utils;
use crate::events::Event;
use crate::events::{Event, EventHandler};
use crate::events::bump_transaction::{AnchorDescriptor, HTLCDescriptor, BumpTransactionEvent};

use crate::prelude::*;
Expand DownExpand Up@@ -738,11 +738,6 @@ impl Readable for IrrevocablyResolvedHTLC {
/// You MUST ensure that no ChannelMonitors for a given channel anywhere contain out-of-date
/// information and are actively monitoring the chain.
///
/// Pending Events or updated HTLCs which have not yet been read out by
/// get_and_clear_pending_monitor_events or get_and_clear_pending_events are serialized to disk and
/// reloaded at deserialize-time. Thus, you must ensure that, when handling events, all events
/// gotten are fully handled before re-serializing the new state.
///
/// Note that the deserializer is only implemented for (BlockHash, ChannelMonitor), which
/// tells you the last block hash which was block_connect()ed. You MUST rescan any blocks along
/// the "reorg path" (ie disconnecting blocks until you find a common ancestor from both the
Expand All@@ -752,7 +747,7 @@ pub struct ChannelMonitor<Signer: WriteableEcdsaChannelSigner> {
	#[cfg(test)]
	pub(crate) inner: Mutex<ChannelMonitorImpl<Signer>>,
	#[cfg(not(test))]
	inner: Mutex<ChannelMonitorImpl<Signer>>,
pub(super) inner: Mutex<ChannelMonitorImpl<Signer>>,
}

#[derive(PartialEq)]
Expand DownExpand Up@@ -829,7 +824,8 @@ pub(crate) struct ChannelMonitorImpl<Signer: WriteableEcdsaChannelSigner> {
	// we further MUST NOT generate events during block/transaction-disconnection.
	pending_monitor_events: Vec<MonitorEvent>,

	pending_events: Vec<Event>,
	pub(super) pending_events: Vec<Event>,
	pub(super) is_processing_pending_events: bool,

	// Used to track on-chain events (i.e., transactions part of channels confirmed on chain) on
	// which to take actions once they reach enough confirmations. Each entry includes the
Expand DownExpand Up@@ -1088,6 +1084,42 @@ impl<Signer: WriteableEcdsaChannelSigner> Writeable for ChannelMonitorImpl<Signe
	}
}

macro_rules! _process_events_body {
	($self_opt: expr, $event_to_handle: expr, $handle_event: expr) => {
 loop {
 let (pending_events, repeated_events);
 if let Some(us) = $self_opt {
 let mut inner = us.inner.lock().unwrap();
 if inner.is_processing_pending_events {
 break;
 }
 inner.is_processing_pending_events = true;

 pending_events = inner.pending_events.clone();
 repeated_events = inner.get_repeated_events();
 } else { break; }
 let num_events = pending_events.len();

 for event in pending_events.into_iter().chain(repeated_events.into_iter()) {
 $event_to_handle = event;
 $handle_event;
Comment thread
wpaulino marked this conversation as resolved.

 }

 if let Some(us) = $self_opt {
 let mut inner = us.inner.lock().unwrap();
 inner.pending_events.drain(..num_events);
 inner.is_processing_pending_events = false;
 if !inner.pending_events.is_empty() {
 // If there's more events to process, go ahead and do so.
 continue;
 }
 }
 break;
Comment thread
wpaulino marked this conversation as resolved.

Comment thread
TheBlueMatt marked this conversation as resolved.

 }
	}
}
pub(super) use _process_events_body as process_events_body;

impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
	/// For lockorder enforcement purposes, we need to have a single site which constructs the
	/// `inner` mutex, otherwise cases where we lock two monitors at the same time (eg in our
Expand DownExpand Up@@ -1179,6 +1211,7 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
 payment_preimages: HashMap::new(),
 pending_monitor_events: Vec::new(),
 pending_events: Vec::new(),
 is_processing_pending_events: false,

 onchain_events_awaiting_threshold_conf: Vec::new(),
 outputs_to_watch,
Expand DownExpand Up@@ -1306,16 +1339,41 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
 self.inner.lock().unwrap().get_and_clear_pending_monitor_events()
	}

	/// Gets the list of pending events which were generated by previous actions, clearing the list
	/// in the process.
	/// Processes [`SpendableOutputs`] events produced from each [`ChannelMonitor`] upon maturity.
	///
	/// For channels featuring anchor outputs, this method will also process [`BumpTransaction`]
	/// events produced from each [`ChannelMonitor`] while there is a balance to claim onchain
	/// within each channel. As the confirmation of a commitment transaction may be critical to the
	/// safety of funds, we recommend invoking this every 30 seconds, or lower if running in an
	/// environment with spotty connections, like on mobile.
	///
	/// This is called by the [`EventsProvider::process_pending_events`] implementation for
	/// [`ChainMonitor`].
	/// An [`EventHandler`] may safely call back to the provider, though this shouldn't be needed in
	/// order to handle these events.
	///
	/// [`SpendableOutputs`]: crate::events::Event::SpendableOutputs
	/// [`BumpTransaction`]: crate::events::Event::BumpTransaction
	pub fn process_pending_events<H: Deref>(&self, handler: &H) where H::Target: EventHandler {
 let mut ev;
 process_events_body!(Some(self), ev, handler.handle_event(ev));
	}

	/// Processes any events asynchronously.
	///
	/// [`EventsProvider::process_pending_events`]: crate::events::EventsProvider::process_pending_events
	/// [`ChainMonitor`]: crate::chain::chainmonitor::ChainMonitor
	/// See [`Self::process_pending_events`] for more information.
	pub async fn process_pending_events_async<Future: core::future::Future, H: Fn(Event) -> Future>(
 &self, handler: &H
	) {
 let mut ev;
 process_events_body!(Some(self), ev, { handler(ev).await });
	}

	#[cfg(test)]
	pub fn get_and_clear_pending_events(&self) -> Vec<Event> {
Comment thread
TheBlueMatt marked this conversation as resolved.

 self.inner.lock().unwrap().get_and_clear_pending_events()
 let mut ret = Vec::new();
 let mut lck = self.inner.lock().unwrap();
 mem::swap(&mut ret, &mut lck.pending_events);
 ret.append(&mut lck.get_repeated_events());
 ret
	}

	pub(crate) fn get_min_seen_secret(&self) -> u64 {
Expand DownExpand Up@@ -2531,10 +2589,13 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitorImpl<Signer> {
 ret
	}

	pub fn get_and_clear_pending_events(&mut self) -> Vec<Event> {
 let mut ret = Vec::new();
 mem::swap(&mut ret, &mut self.pending_events);
Comment thread
TheBlueMatt marked this conversation as resolved.

 for (claim_id, claim_event) in self.onchain_tx_handler.get_and_clear_pending_claim_events().drain(..) {
	/// Gets the set of events that are repeated regularly (e.g. those which RBF bump
	/// transactions). We're okay if we lose these on restart as they'll be regenerated for us at
	/// some regular interval via [`ChannelMonitor::rebroadcast_pending_claims`].
	pub(super) fn get_repeated_events(&mut self) -> Vec<Event> {
 let pending_claim_events = self.onchain_tx_handler.get_and_clear_pending_claim_events();
 let mut ret = Vec::with_capacity(pending_claim_events.len());
 for (claim_id, claim_event) in pending_claim_events {
 match claim_event {
 ClaimEvent::BumpCommitment {
 package_target_feerate_sat_per_1000_weight, commitment_tx, anchor_output_idx,
Expand DownExpand Up@@ -4096,6 +4157,7 @@ impl<'a, 'b, ES: EntropySource, SP: SignerProvider> ReadableArgs<(&'a ES, &'b SP
 payment_preimages,
 pending_monitor_events: pending_monitor_events.unwrap(),
 pending_events,
 is_processing_pending_events: false,

 onchain_events_awaiting_threshold_conf,
 outputs_to_watch,
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Don't drop ChannelMonitor Events until they're processed#2369

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.

 Sign up for GitHub

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

 Merged

wpaulino
merged 1 commit into

from

Jul 10, 2023
 Merged


Don't drop ChannelMonitor Events until they're processed
#2369
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


1 commit


Select commit


File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


19 changes: 8 additions & 11 deletions
lightning/src/chain/chainmonitor.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -520,12 +520,13 @@ where C::Target: chain::Filter,
	pub async fn process_pending_events_async<Future: core::future::Future, H: Fn(Event) -> Future>(
 &self, handler: H
	) {
 let mut pending_events = Vec::new();
 for monitor_state in self.monitors.read().unwrap().values() {
 pending_events.append(&mut monitor_state.monitor.get_and_clear_pending_events());
 }
 for event in pending_events {
 handler(event).await;
 // Sadly we can't hold the monitors read lock through an async call. Thus we have to do a
 // crazy dance to process a monitor's events then only remove them once we've done so.
 let mons_to_process = self.monitors.read().unwrap().keys().cloned().collect::<Vec<_>>();
 for funding_txo in mons_to_process {
 let mut ev;
 super::channelmonitor::process_events_body!(
 self.monitors.read().unwrap().get(&funding_txo).map(|m| &m.monitor), ev, handler(ev).await);
@alecchendevalecchendevJul 6, 2023

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

Will this first argument ever be None?
@TheBlueMattTheBlueMattJul 7, 2023

Copy link


Copy Markdown

CollaboratorAuthor
Choose a reason for hiding this comment

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

Currently I don't think so, but in the future we probably want to support removing monitors after they're done with all their processing (and probably will do so automatically). Thus, we should handle the case where the monitor has dissapeared on us (we don't hold a lock through the loop anyway, so its good practice to not rely on any assumptions about the underlying data changing).
 }
	}

Expand DownExpand Up@@ -796,12 +797,8 @@ impl<ChannelSigner: WriteableEcdsaChannelSigner, C: Deref, T: Deref, F: Deref, L
	/// [`SpendableOutputs`]: events::Event::SpendableOutputs
	/// [`BumpTransaction`]: events::Event::BumpTransaction
	fn process_pending_events<H: Deref>(&self, handler: H) where H::Target: EventHandler {
 let mut pending_events = Vec::new();
 for monitor_state in self.monitors.read().unwrap().values() {
 pending_events.append(&mut monitor_state.monitor.get_and_clear_pending_events());
 }
 for event in pending_events {
 handler.handle_event(event);
 monitor_state.monitor.process_pending_events(&handler);
 }
	}
}
Expand Down

100 changes: 81 additions & 19 deletions
lightning/src/chain/channelmonitor.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -49,7 +49,7 @@ use crate::chain::Filter;
use crate::util::logger::Logger;
use crate::util::ser::{Readable, ReadableArgs, RequiredWrapper, MaybeReadable, UpgradableRequired, Writer, Writeable, U48};
use crate::util::byte_utils;
use crate::events::Event;
use crate::events::{Event, EventHandler};
use crate::events::bump_transaction::{AnchorDescriptor, HTLCDescriptor, BumpTransactionEvent};

use crate::prelude::*;
Expand DownExpand Up@@ -738,11 +738,6 @@ impl Readable for IrrevocablyResolvedHTLC {
/// You MUST ensure that no ChannelMonitors for a given channel anywhere contain out-of-date
/// information and are actively monitoring the chain.
///
/// Pending Events or updated HTLCs which have not yet been read out by
/// get_and_clear_pending_monitor_events or get_and_clear_pending_events are serialized to disk and
/// reloaded at deserialize-time. Thus, you must ensure that, when handling events, all events
/// gotten are fully handled before re-serializing the new state.
///
/// Note that the deserializer is only implemented for (BlockHash, ChannelMonitor), which
/// tells you the last block hash which was block_connect()ed. You MUST rescan any blocks along
/// the "reorg path" (ie disconnecting blocks until you find a common ancestor from both the
Expand All@@ -752,7 +747,7 @@ pub struct ChannelMonitor<Signer: WriteableEcdsaChannelSigner> {
	#[cfg(test)]
	pub(crate) inner: Mutex<ChannelMonitorImpl<Signer>>,
	#[cfg(not(test))]
	inner: Mutex<ChannelMonitorImpl<Signer>>,
pub(super) inner: Mutex<ChannelMonitorImpl<Signer>>,
}

#[derive(PartialEq)]
Expand DownExpand Up@@ -829,7 +824,8 @@ pub(crate) struct ChannelMonitorImpl<Signer: WriteableEcdsaChannelSigner> {
	// we further MUST NOT generate events during block/transaction-disconnection.
	pending_monitor_events: Vec<MonitorEvent>,

	pending_events: Vec<Event>,
	pub(super) pending_events: Vec<Event>,
	pub(super) is_processing_pending_events: bool,

	// Used to track on-chain events (i.e., transactions part of channels confirmed on chain) on
	// which to take actions once they reach enough confirmations. Each entry includes the
Expand DownExpand Up@@ -1088,6 +1084,42 @@ impl<Signer: WriteableEcdsaChannelSigner> Writeable for ChannelMonitorImpl<Signe
	}
}

macro_rules! _process_events_body {
	($self_opt: expr, $event_to_handle: expr, $handle_event: expr) => {
 loop {
 let (pending_events, repeated_events);
 if let Some(us) = $self_opt {
 let mut inner = us.inner.lock().unwrap();
 if inner.is_processing_pending_events {
 break;
 }
 inner.is_processing_pending_events = true;

 pending_events = inner.pending_events.clone();
 repeated_events = inner.get_repeated_events();
 } else { break; }
 let num_events = pending_events.len();

 for event in pending_events.into_iter().chain(repeated_events.into_iter()) {
 $event_to_handle = event;
 $handle_event;
Comment thread
wpaulino marked this conversation as resolved.

 }

 if let Some(us) = $self_opt {
 let mut inner = us.inner.lock().unwrap();
 inner.pending_events.drain(..num_events);
 inner.is_processing_pending_events = false;
 if !inner.pending_events.is_empty() {
 // If there's more events to process, go ahead and do so.
 continue;
 }
 }
 break;
Comment thread
wpaulino marked this conversation as resolved.

Comment thread
TheBlueMatt marked this conversation as resolved.

 }
	}
}
pub(super) use _process_events_body as process_events_body;

impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
	/// For lockorder enforcement purposes, we need to have a single site which constructs the
	/// `inner` mutex, otherwise cases where we lock two monitors at the same time (eg in our
Expand DownExpand Up@@ -1179,6 +1211,7 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
 payment_preimages: HashMap::new(),
 pending_monitor_events: Vec::new(),
 pending_events: Vec::new(),
 is_processing_pending_events: false,

 onchain_events_awaiting_threshold_conf: Vec::new(),
 outputs_to_watch,
Expand DownExpand Up@@ -1306,16 +1339,41 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
 self.inner.lock().unwrap().get_and_clear_pending_monitor_events()
	}

	/// Gets the list of pending events which were generated by previous actions, clearing the list
	/// in the process.
	/// Processes [`SpendableOutputs`] events produced from each [`ChannelMonitor`] upon maturity.
	///
	/// For channels featuring anchor outputs, this method will also process [`BumpTransaction`]
	/// events produced from each [`ChannelMonitor`] while there is a balance to claim onchain
	/// within each channel. As the confirmation of a commitment transaction may be critical to the
	/// safety of funds, we recommend invoking this every 30 seconds, or lower if running in an
	/// environment with spotty connections, like on mobile.
	///
	/// This is called by the [`EventsProvider::process_pending_events`] implementation for
	/// [`ChainMonitor`].
	/// An [`EventHandler`] may safely call back to the provider, though this shouldn't be needed in
	/// order to handle these events.
	///
	/// [`SpendableOutputs`]: crate::events::Event::SpendableOutputs
	/// [`BumpTransaction`]: crate::events::Event::BumpTransaction
	pub fn process_pending_events<H: Deref>(&self, handler: &H) where H::Target: EventHandler {
 let mut ev;
 process_events_body!(Some(self), ev, handler.handle_event(ev));
	}

	/// Processes any events asynchronously.
	///
	/// [`EventsProvider::process_pending_events`]: crate::events::EventsProvider::process_pending_events
	/// [`ChainMonitor`]: crate::chain::chainmonitor::ChainMonitor
	/// See [`Self::process_pending_events`] for more information.
	pub async fn process_pending_events_async<Future: core::future::Future, H: Fn(Event) -> Future>(
 &self, handler: &H
	) {
 let mut ev;
 process_events_body!(Some(self), ev, { handler(ev).await });
	}

	#[cfg(test)]
	pub fn get_and_clear_pending_events(&self) -> Vec<Event> {
Comment thread
TheBlueMatt marked this conversation as resolved.

 self.inner.lock().unwrap().get_and_clear_pending_events()
 let mut ret = Vec::new();
 let mut lck = self.inner.lock().unwrap();
 mem::swap(&mut ret, &mut lck.pending_events);
 ret.append(&mut lck.get_repeated_events());
 ret
	}

	pub(crate) fn get_min_seen_secret(&self) -> u64 {
Expand DownExpand Up@@ -2531,10 +2589,13 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitorImpl<Signer> {
 ret
	}

	pub fn get_and_clear_pending_events(&mut self) -> Vec<Event> {
 let mut ret = Vec::new();
 mem::swap(&mut ret, &mut self.pending_events);
Comment thread
TheBlueMatt marked this conversation as resolved.

 for (claim_id, claim_event) in self.onchain_tx_handler.get_and_clear_pending_claim_events().drain(..) {
	/// Gets the set of events that are repeated regularly (e.g. those which RBF bump
	/// transactions). We're okay if we lose these on restart as they'll be regenerated for us at
	/// some regular interval via [`ChannelMonitor::rebroadcast_pending_claims`].
	pub(super) fn get_repeated_events(&mut self) -> Vec<Event> {
 let pending_claim_events = self.onchain_tx_handler.get_and_clear_pending_claim_events();
 let mut ret = Vec::with_capacity(pending_claim_events.len());
 for (claim_id, claim_event) in pending_claim_events {
 match claim_event {
 ClaimEvent::BumpCommitment {
 package_target_feerate_sat_per_1000_weight, commitment_tx, anchor_output_idx,
Expand DownExpand Up@@ -4096,6 +4157,7 @@ impl<'a, 'b, ES: EntropySource, SP: SignerProvider> ReadableArgs<(&'a ES, &'b SP
 payment_preimages,
 pending_monitor_events: pending_monitor_events.unwrap(),
 pending_events,
 is_processing_pending_events: false,

 onchain_events_awaiting_threshold_conf,
 outputs_to_watch,
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
Don't drop ChannelMonitor Events until they're processed#2369

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.

 Sign up for GitHub

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

 Merged

wpaulino
merged 1 commit into

from

Jul 10, 2023
 Merged


Don't drop ChannelMonitor Events until they're processed
#2369
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


1 commit


Select commit


File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


19 changes: 8 additions & 11 deletions
lightning/src/chain/chainmonitor.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -520,12 +520,13 @@ where C::Target: chain::Filter,
	pub async fn process_pending_events_async<Future: core::future::Future, H: Fn(Event) -> Future>(
 &self, handler: H
	) {
 let mut pending_events = Vec::new();
 for monitor_state in self.monitors.read().unwrap().values() {
 pending_events.append(&mut monitor_state.monitor.get_and_clear_pending_events());
 }
 for event in pending_events {
 handler(event).await;
 // Sadly we can't hold the monitors read lock through an async call. Thus we have to do a
 // crazy dance to process a monitor's events then only remove them once we've done so.
 let mons_to_process = self.monitors.read().unwrap().keys().cloned().collect::<Vec<_>>();
 for funding_txo in mons_to_process {
 let mut ev;
 super::channelmonitor::process_events_body!(
 self.monitors.read().unwrap().get(&funding_txo).map(|m| &m.monitor), ev, handler(ev).await);
@alecchendevalecchendevJul 6, 2023

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

Will this first argument ever be None?
@TheBlueMattTheBlueMattJul 7, 2023

Copy link


Copy Markdown

CollaboratorAuthor
Choose a reason for hiding this comment

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

Currently I don't think so, but in the future we probably want to support removing monitors after they're done with all their processing (and probably will do so automatically). Thus, we should handle the case where the monitor has dissapeared on us (we don't hold a lock through the loop anyway, so its good practice to not rely on any assumptions about the underlying data changing).
 }
	}

Expand DownExpand Up@@ -796,12 +797,8 @@ impl<ChannelSigner: WriteableEcdsaChannelSigner, C: Deref, T: Deref, F: Deref, L
	/// [`SpendableOutputs`]: events::Event::SpendableOutputs
	/// [`BumpTransaction`]: events::Event::BumpTransaction
	fn process_pending_events<H: Deref>(&self, handler: H) where H::Target: EventHandler {
 let mut pending_events = Vec::new();
 for monitor_state in self.monitors.read().unwrap().values() {
 pending_events.append(&mut monitor_state.monitor.get_and_clear_pending_events());
 }
 for event in pending_events {
 handler.handle_event(event);
 monitor_state.monitor.process_pending_events(&handler);
 }
	}
}
Expand Down

100 changes: 81 additions & 19 deletions
lightning/src/chain/channelmonitor.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -49,7 +49,7 @@ use crate::chain::Filter;
use crate::util::logger::Logger;
use crate::util::ser::{Readable, ReadableArgs, RequiredWrapper, MaybeReadable, UpgradableRequired, Writer, Writeable, U48};
use crate::util::byte_utils;
use crate::events::Event;
use crate::events::{Event, EventHandler};
use crate::events::bump_transaction::{AnchorDescriptor, HTLCDescriptor, BumpTransactionEvent};

use crate::prelude::*;
Expand DownExpand Up@@ -738,11 +738,6 @@ impl Readable for IrrevocablyResolvedHTLC {
/// You MUST ensure that no ChannelMonitors for a given channel anywhere contain out-of-date
/// information and are actively monitoring the chain.
///
/// Pending Events or updated HTLCs which have not yet been read out by
/// get_and_clear_pending_monitor_events or get_and_clear_pending_events are serialized to disk and
/// reloaded at deserialize-time. Thus, you must ensure that, when handling events, all events
/// gotten are fully handled before re-serializing the new state.
///
/// Note that the deserializer is only implemented for (BlockHash, ChannelMonitor), which
/// tells you the last block hash which was block_connect()ed. You MUST rescan any blocks along
/// the "reorg path" (ie disconnecting blocks until you find a common ancestor from both the
Expand All@@ -752,7 +747,7 @@ pub struct ChannelMonitor<Signer: WriteableEcdsaChannelSigner> {
	#[cfg(test)]
	pub(crate) inner: Mutex<ChannelMonitorImpl<Signer>>,
	#[cfg(not(test))]
	inner: Mutex<ChannelMonitorImpl<Signer>>,
pub(super) inner: Mutex<ChannelMonitorImpl<Signer>>,
}

#[derive(PartialEq)]
Expand DownExpand Up@@ -829,7 +824,8 @@ pub(crate) struct ChannelMonitorImpl<Signer: WriteableEcdsaChannelSigner> {
	// we further MUST NOT generate events during block/transaction-disconnection.
	pending_monitor_events: Vec<MonitorEvent>,

	pending_events: Vec<Event>,
	pub(super) pending_events: Vec<Event>,
	pub(super) is_processing_pending_events: bool,

	// Used to track on-chain events (i.e., transactions part of channels confirmed on chain) on
	// which to take actions once they reach enough confirmations. Each entry includes the
Expand DownExpand Up@@ -1088,6 +1084,42 @@ impl<Signer: WriteableEcdsaChannelSigner> Writeable for ChannelMonitorImpl<Signe
	}
}

macro_rules! _process_events_body {
	($self_opt: expr, $event_to_handle: expr, $handle_event: expr) => {
 loop {
 let (pending_events, repeated_events);
 if let Some(us) = $self_opt {
 let mut inner = us.inner.lock().unwrap();
 if inner.is_processing_pending_events {
 break;
 }
 inner.is_processing_pending_events = true;

 pending_events = inner.pending_events.clone();
 repeated_events = inner.get_repeated_events();
 } else { break; }
 let num_events = pending_events.len();

 for event in pending_events.into_iter().chain(repeated_events.into_iter()) {
 $event_to_handle = event;
 $handle_event;
Comment thread
wpaulino marked this conversation as resolved.

 }

 if let Some(us) = $self_opt {
 let mut inner = us.inner.lock().unwrap();
 inner.pending_events.drain(..num_events);
 inner.is_processing_pending_events = false;
 if !inner.pending_events.is_empty() {
 // If there's more events to process, go ahead and do so.
 continue;
 }
 }
 break;
Comment thread
wpaulino marked this conversation as resolved.

Comment thread
TheBlueMatt marked this conversation as resolved.

 }
	}
}
pub(super) use _process_events_body as process_events_body;

impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
	/// For lockorder enforcement purposes, we need to have a single site which constructs the
	/// `inner` mutex, otherwise cases where we lock two monitors at the same time (eg in our
Expand DownExpand Up@@ -1179,6 +1211,7 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
 payment_preimages: HashMap::new(),
 pending_monitor_events: Vec::new(),
 pending_events: Vec::new(),
 is_processing_pending_events: false,

 onchain_events_awaiting_threshold_conf: Vec::new(),
 outputs_to_watch,
Expand DownExpand Up@@ -1306,16 +1339,41 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
 self.inner.lock().unwrap().get_and_clear_pending_monitor_events()
	}

	/// Gets the list of pending events which were generated by previous actions, clearing the list
	/// in the process.
	/// Processes [`SpendableOutputs`] events produced from each [`ChannelMonitor`] upon maturity.
	///
	/// For channels featuring anchor outputs, this method will also process [`BumpTransaction`]
	/// events produced from each [`ChannelMonitor`] while there is a balance to claim onchain
	/// within each channel. As the confirmation of a commitment transaction may be critical to the
	/// safety of funds, we recommend invoking this every 30 seconds, or lower if running in an
	/// environment with spotty connections, like on mobile.
	///
	/// This is called by the [`EventsProvider::process_pending_events`] implementation for
	/// [`ChainMonitor`].
	/// An [`EventHandler`] may safely call back to the provider, though this shouldn't be needed in
	/// order to handle these events.
	///
	/// [`SpendableOutputs`]: crate::events::Event::SpendableOutputs
	/// [`BumpTransaction`]: crate::events::Event::BumpTransaction
	pub fn process_pending_events<H: Deref>(&self, handler: &H) where H::Target: EventHandler {
 let mut ev;
 process_events_body!(Some(self), ev, handler.handle_event(ev));
	}

	/// Processes any events asynchronously.
	///
	/// [`EventsProvider::process_pending_events`]: crate::events::EventsProvider::process_pending_events
	/// [`ChainMonitor`]: crate::chain::chainmonitor::ChainMonitor
	/// See [`Self::process_pending_events`] for more information.
	pub async fn process_pending_events_async<Future: core::future::Future, H: Fn(Event) -> Future>(
 &self, handler: &H
	) {
 let mut ev;
 process_events_body!(Some(self), ev, { handler(ev).await });
	}

	#[cfg(test)]
	pub fn get_and_clear_pending_events(&self) -> Vec<Event> {
Comment thread
TheBlueMatt marked this conversation as resolved.

 self.inner.lock().unwrap().get_and_clear_pending_events()
 let mut ret = Vec::new();
 let mut lck = self.inner.lock().unwrap();
 mem::swap(&mut ret, &mut lck.pending_events);
 ret.append(&mut lck.get_repeated_events());
 ret
	}

	pub(crate) fn get_min_seen_secret(&self) -> u64 {
Expand DownExpand Up@@ -2531,10 +2589,13 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitorImpl<Signer> {
 ret
	}

	pub fn get_and_clear_pending_events(&mut self) -> Vec<Event> {
 let mut ret = Vec::new();
 mem::swap(&mut ret, &mut self.pending_events);
Comment thread
TheBlueMatt marked this conversation as resolved.

 for (claim_id, claim_event) in self.onchain_tx_handler.get_and_clear_pending_claim_events().drain(..) {
	/// Gets the set of events that are repeated regularly (e.g. those which RBF bump
	/// transactions). We're okay if we lose these on restart as they'll be regenerated for us at
	/// some regular interval via [`ChannelMonitor::rebroadcast_pending_claims`].
	pub(super) fn get_repeated_events(&mut self) -> Vec<Event> {
 let pending_claim_events = self.onchain_tx_handler.get_and_clear_pending_claim_events();
 let mut ret = Vec::with_capacity(pending_claim_events.len());
 for (claim_id, claim_event) in pending_claim_events {
 match claim_event {
 ClaimEvent::BumpCommitment {
 package_target_feerate_sat_per_1000_weight, commitment_tx, anchor_output_idx,
Expand DownExpand Up@@ -4096,6 +4157,7 @@ impl<'a, 'b, ES: EntropySource, SP: SignerProvider> ReadableArgs<(&'a ES, &'b SP
 payment_preimages,
 pending_monitor_events: pending_monitor_events.unwrap(),
 pending_events,
 is_processing_pending_events: false,

 onchain_events_awaiting_threshold_conf,
 outputs_to_watch,
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Don't drop ChannelMonitor Events until they're processed#2369

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.

 Sign up for GitHub

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

 Merged

wpaulino
merged 1 commit into

from

Jul 10, 2023
 Merged


Don't drop ChannelMonitor Events until they're processed
#2369
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


1 commit


Select commit


File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


19 changes: 8 additions & 11 deletions
lightning/src/chain/chainmonitor.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -520,12 +520,13 @@ where C::Target: chain::Filter,
	pub async fn process_pending_events_async<Future: core::future::Future, H: Fn(Event) -> Future>(
 &self, handler: H
	) {
 let mut pending_events = Vec::new();
 for monitor_state in self.monitors.read().unwrap().values() {
 pending_events.append(&mut monitor_state.monitor.get_and_clear_pending_events());
 }
 for event in pending_events {
 handler(event).await;
 // Sadly we can't hold the monitors read lock through an async call. Thus we have to do a
 // crazy dance to process a monitor's events then only remove them once we've done so.
 let mons_to_process = self.monitors.read().unwrap().keys().cloned().collect::<Vec<_>>();
 for funding_txo in mons_to_process {
 let mut ev;
 super::channelmonitor::process_events_body!(
 self.monitors.read().unwrap().get(&funding_txo).map(|m| &m.monitor), ev, handler(ev).await);
@alecchendevalecchendevJul 6, 2023

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

Will this first argument ever be None?
@TheBlueMattTheBlueMattJul 7, 2023

Copy link


Copy Markdown

CollaboratorAuthor
Choose a reason for hiding this comment

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

Currently I don't think so, but in the future we probably want to support removing monitors after they're done with all their processing (and probably will do so automatically). Thus, we should handle the case where the monitor has dissapeared on us (we don't hold a lock through the loop anyway, so its good practice to not rely on any assumptions about the underlying data changing).
 }
	}

Expand DownExpand Up@@ -796,12 +797,8 @@ impl<ChannelSigner: WriteableEcdsaChannelSigner, C: Deref, T: Deref, F: Deref, L
	/// [`SpendableOutputs`]: events::Event::SpendableOutputs
	/// [`BumpTransaction`]: events::Event::BumpTransaction
	fn process_pending_events<H: Deref>(&self, handler: H) where H::Target: EventHandler {
 let mut pending_events = Vec::new();
 for monitor_state in self.monitors.read().unwrap().values() {
 pending_events.append(&mut monitor_state.monitor.get_and_clear_pending_events());
 }
 for event in pending_events {
 handler.handle_event(event);
 monitor_state.monitor.process_pending_events(&handler);
 }
	}
}
Expand Down

100 changes: 81 additions & 19 deletions
lightning/src/chain/channelmonitor.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -49,7 +49,7 @@ use crate::chain::Filter;
use crate::util::logger::Logger;
use crate::util::ser::{Readable, ReadableArgs, RequiredWrapper, MaybeReadable, UpgradableRequired, Writer, Writeable, U48};
use crate::util::byte_utils;
use crate::events::Event;
use crate::events::{Event, EventHandler};
use crate::events::bump_transaction::{AnchorDescriptor, HTLCDescriptor, BumpTransactionEvent};

use crate::prelude::*;
Expand DownExpand Up@@ -738,11 +738,6 @@ impl Readable for IrrevocablyResolvedHTLC {
/// You MUST ensure that no ChannelMonitors for a given channel anywhere contain out-of-date
/// information and are actively monitoring the chain.
///
/// Pending Events or updated HTLCs which have not yet been read out by
/// get_and_clear_pending_monitor_events or get_and_clear_pending_events are serialized to disk and
/// reloaded at deserialize-time. Thus, you must ensure that, when handling events, all events
/// gotten are fully handled before re-serializing the new state.
///
/// Note that the deserializer is only implemented for (BlockHash, ChannelMonitor), which
/// tells you the last block hash which was block_connect()ed. You MUST rescan any blocks along
/// the "reorg path" (ie disconnecting blocks until you find a common ancestor from both the
Expand All@@ -752,7 +747,7 @@ pub struct ChannelMonitor<Signer: WriteableEcdsaChannelSigner> {
	#[cfg(test)]
	pub(crate) inner: Mutex<ChannelMonitorImpl<Signer>>,
	#[cfg(not(test))]
	inner: Mutex<ChannelMonitorImpl<Signer>>,
pub(super) inner: Mutex<ChannelMonitorImpl<Signer>>,
}

#[derive(PartialEq)]
Expand DownExpand Up@@ -829,7 +824,8 @@ pub(crate) struct ChannelMonitorImpl<Signer: WriteableEcdsaChannelSigner> {
	// we further MUST NOT generate events during block/transaction-disconnection.
	pending_monitor_events: Vec<MonitorEvent>,

	pending_events: Vec<Event>,
	pub(super) pending_events: Vec<Event>,
	pub(super) is_processing_pending_events: bool,

	// Used to track on-chain events (i.e., transactions part of channels confirmed on chain) on
	// which to take actions once they reach enough confirmations. Each entry includes the
Expand DownExpand Up@@ -1088,6 +1084,42 @@ impl<Signer: WriteableEcdsaChannelSigner> Writeable for ChannelMonitorImpl<Signe
	}
}

macro_rules! _process_events_body {
	($self_opt: expr, $event_to_handle: expr, $handle_event: expr) => {
 loop {
 let (pending_events, repeated_events);
 if let Some(us) = $self_opt {
 let mut inner = us.inner.lock().unwrap();
 if inner.is_processing_pending_events {
 break;
 }
 inner.is_processing_pending_events = true;

 pending_events = inner.pending_events.clone();
 repeated_events = inner.get_repeated_events();
 } else { break; }
 let num_events = pending_events.len();

 for event in pending_events.into_iter().chain(repeated_events.into_iter()) {
 $event_to_handle = event;
 $handle_event;
Comment thread
wpaulino marked this conversation as resolved.

 }

 if let Some(us) = $self_opt {
 let mut inner = us.inner.lock().unwrap();
 inner.pending_events.drain(..num_events);
 inner.is_processing_pending_events = false;
 if !inner.pending_events.is_empty() {
 // If there's more events to process, go ahead and do so.
 continue;
 }
 }
 break;
Comment thread
wpaulino marked this conversation as resolved.

Comment thread
TheBlueMatt marked this conversation as resolved.

 }
	}
}
pub(super) use _process_events_body as process_events_body;

impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
	/// For lockorder enforcement purposes, we need to have a single site which constructs the
	/// `inner` mutex, otherwise cases where we lock two monitors at the same time (eg in our
Expand DownExpand Up@@ -1179,6 +1211,7 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
 payment_preimages: HashMap::new(),
 pending_monitor_events: Vec::new(),
 pending_events: Vec::new(),
 is_processing_pending_events: false,

 onchain_events_awaiting_threshold_conf: Vec::new(),
 outputs_to_watch,
Expand DownExpand Up@@ -1306,16 +1339,41 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
 self.inner.lock().unwrap().get_and_clear_pending_monitor_events()
	}

	/// Gets the list of pending events which were generated by previous actions, clearing the list
	/// in the process.
	/// Processes [`SpendableOutputs`] events produced from each [`ChannelMonitor`] upon maturity.
	///
	/// For channels featuring anchor outputs, this method will also process [`BumpTransaction`]
	/// events produced from each [`ChannelMonitor`] while there is a balance to claim onchain
	/// within each channel. As the confirmation of a commitment transaction may be critical to the
	/// safety of funds, we recommend invoking this every 30 seconds, or lower if running in an
	/// environment with spotty connections, like on mobile.
	///
	/// This is called by the [`EventsProvider::process_pending_events`] implementation for
	/// [`ChainMonitor`].
	/// An [`EventHandler`] may safely call back to the provider, though this shouldn't be needed in
	/// order to handle these events.
	///
	/// [`SpendableOutputs`]: crate::events::Event::SpendableOutputs
	/// [`BumpTransaction`]: crate::events::Event::BumpTransaction
	pub fn process_pending_events<H: Deref>(&self, handler: &H) where H::Target: EventHandler {
 let mut ev;
 process_events_body!(Some(self), ev, handler.handle_event(ev));
	}

	/// Processes any events asynchronously.
	///
	/// [`EventsProvider::process_pending_events`]: crate::events::EventsProvider::process_pending_events
	/// [`ChainMonitor`]: crate::chain::chainmonitor::ChainMonitor
	/// See [`Self::process_pending_events`] for more information.
	pub async fn process_pending_events_async<Future: core::future::Future, H: Fn(Event) -> Future>(
 &self, handler: &H
	) {
 let mut ev;
 process_events_body!(Some(self), ev, { handler(ev).await });
	}

	#[cfg(test)]
	pub fn get_and_clear_pending_events(&self) -> Vec<Event> {
Comment thread
TheBlueMatt marked this conversation as resolved.

 self.inner.lock().unwrap().get_and_clear_pending_events()
 let mut ret = Vec::new();
 let mut lck = self.inner.lock().unwrap();
 mem::swap(&mut ret, &mut lck.pending_events);
 ret.append(&mut lck.get_repeated_events());
 ret
	}

	pub(crate) fn get_min_seen_secret(&self) -> u64 {
Expand DownExpand Up@@ -2531,10 +2589,13 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitorImpl<Signer> {
 ret
	}

	pub fn get_and_clear_pending_events(&mut self) -> Vec<Event> {
 let mut ret = Vec::new();
 mem::swap(&mut ret, &mut self.pending_events);
Comment thread
TheBlueMatt marked this conversation as resolved.

 for (claim_id, claim_event) in self.onchain_tx_handler.get_and_clear_pending_claim_events().drain(..) {
	/// Gets the set of events that are repeated regularly (e.g. those which RBF bump
	/// transactions). We're okay if we lose these on restart as they'll be regenerated for us at
	/// some regular interval via [`ChannelMonitor::rebroadcast_pending_claims`].
	pub(super) fn get_repeated_events(&mut self) -> Vec<Event> {
 let pending_claim_events = self.onchain_tx_handler.get_and_clear_pending_claim_events();
 let mut ret = Vec::with_capacity(pending_claim_events.len());
 for (claim_id, claim_event) in pending_claim_events {
 match claim_event {
 ClaimEvent::BumpCommitment {
 package_target_feerate_sat_per_1000_weight, commitment_tx, anchor_output_idx,
Expand DownExpand Up@@ -4096,6 +4157,7 @@ impl<'a, 'b, ES: EntropySource, SP: SignerProvider> ReadableArgs<(&'a ES, &'b SP
 payment_preimages,
 pending_monitor_events: pending_monitor_events.unwrap(),
 pending_events,
 is_processing_pending_events: false,

 onchain_events_awaiting_threshold_conf,
 outputs_to_watch,
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Don't drop ChannelMonitor Events until they're processed#2369

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.

 Sign up for GitHub

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

 Merged

wpaulino
merged 1 commit into

from

Jul 10, 2023
 Merged


Don't drop ChannelMonitor Events until they're processed
#2369
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


1 commit


Select commit


File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


19 changes: 8 additions & 11 deletions
lightning/src/chain/chainmonitor.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -520,12 +520,13 @@ where C::Target: chain::Filter,
	pub async fn process_pending_events_async<Future: core::future::Future, H: Fn(Event) -> Future>(
 &self, handler: H
	) {
 let mut pending_events = Vec::new();
 for monitor_state in self.monitors.read().unwrap().values() {
 pending_events.append(&mut monitor_state.monitor.get_and_clear_pending_events());
 }
 for event in pending_events {
 handler(event).await;
 // Sadly we can't hold the monitors read lock through an async call. Thus we have to do a
 // crazy dance to process a monitor's events then only remove them once we've done so.
 let mons_to_process = self.monitors.read().unwrap().keys().cloned().collect::<Vec<_>>();
 for funding_txo in mons_to_process {
 let mut ev;
 super::channelmonitor::process_events_body!(
 self.monitors.read().unwrap().get(&funding_txo).map(|m| &m.monitor), ev, handler(ev).await);
@alecchendevalecchendevJul 6, 2023

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

Will this first argument ever be None?
@TheBlueMattTheBlueMattJul 7, 2023

Copy link


Copy Markdown

CollaboratorAuthor
Choose a reason for hiding this comment

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

Currently I don't think so, but in the future we probably want to support removing monitors after they're done with all their processing (and probably will do so automatically). Thus, we should handle the case where the monitor has dissapeared on us (we don't hold a lock through the loop anyway, so its good practice to not rely on any assumptions about the underlying data changing).
 }
	}

Expand DownExpand Up@@ -796,12 +797,8 @@ impl<ChannelSigner: WriteableEcdsaChannelSigner, C: Deref, T: Deref, F: Deref, L
	/// [`SpendableOutputs`]: events::Event::SpendableOutputs
	/// [`BumpTransaction`]: events::Event::BumpTransaction
	fn process_pending_events<H: Deref>(&self, handler: H) where H::Target: EventHandler {
 let mut pending_events = Vec::new();
 for monitor_state in self.monitors.read().unwrap().values() {
 pending_events.append(&mut monitor_state.monitor.get_and_clear_pending_events());
 }
 for event in pending_events {
 handler.handle_event(event);
 monitor_state.monitor.process_pending_events(&handler);
 }
	}
}
Expand Down

100 changes: 81 additions & 19 deletions
lightning/src/chain/channelmonitor.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -49,7 +49,7 @@ use crate::chain::Filter;
use crate::util::logger::Logger;
use crate::util::ser::{Readable, ReadableArgs, RequiredWrapper, MaybeReadable, UpgradableRequired, Writer, Writeable, U48};
use crate::util::byte_utils;
use crate::events::Event;
use crate::events::{Event, EventHandler};
use crate::events::bump_transaction::{AnchorDescriptor, HTLCDescriptor, BumpTransactionEvent};

use crate::prelude::*;
Expand DownExpand Up@@ -738,11 +738,6 @@ impl Readable for IrrevocablyResolvedHTLC {
/// You MUST ensure that no ChannelMonitors for a given channel anywhere contain out-of-date
/// information and are actively monitoring the chain.
///
/// Pending Events or updated HTLCs which have not yet been read out by
/// get_and_clear_pending_monitor_events or get_and_clear_pending_events are serialized to disk and
/// reloaded at deserialize-time. Thus, you must ensure that, when handling events, all events
/// gotten are fully handled before re-serializing the new state.
///
/// Note that the deserializer is only implemented for (BlockHash, ChannelMonitor), which
/// tells you the last block hash which was block_connect()ed. You MUST rescan any blocks along
/// the "reorg path" (ie disconnecting blocks until you find a common ancestor from both the
Expand All@@ -752,7 +747,7 @@ pub struct ChannelMonitor<Signer: WriteableEcdsaChannelSigner> {
	#[cfg(test)]
	pub(crate) inner: Mutex<ChannelMonitorImpl<Signer>>,
	#[cfg(not(test))]
	inner: Mutex<ChannelMonitorImpl<Signer>>,
pub(super) inner: Mutex<ChannelMonitorImpl<Signer>>,
}

#[derive(PartialEq)]
Expand DownExpand Up@@ -829,7 +824,8 @@ pub(crate) struct ChannelMonitorImpl<Signer: WriteableEcdsaChannelSigner> {
	// we further MUST NOT generate events during block/transaction-disconnection.
	pending_monitor_events: Vec<MonitorEvent>,

	pending_events: Vec<Event>,
	pub(super) pending_events: Vec<Event>,
	pub(super) is_processing_pending_events: bool,

	// Used to track on-chain events (i.e., transactions part of channels confirmed on chain) on
	// which to take actions once they reach enough confirmations. Each entry includes the
Expand DownExpand Up@@ -1088,6 +1084,42 @@ impl<Signer: WriteableEcdsaChannelSigner> Writeable for ChannelMonitorImpl<Signe
	}
}

macro_rules! _process_events_body {
	($self_opt: expr, $event_to_handle: expr, $handle_event: expr) => {
 loop {
 let (pending_events, repeated_events);
 if let Some(us) = $self_opt {
 let mut inner = us.inner.lock().unwrap();
 if inner.is_processing_pending_events {
 break;
 }
 inner.is_processing_pending_events = true;

 pending_events = inner.pending_events.clone();
 repeated_events = inner.get_repeated_events();
 } else { break; }
 let num_events = pending_events.len();

 for event in pending_events.into_iter().chain(repeated_events.into_iter()) {
 $event_to_handle = event;
 $handle_event;
Comment thread
wpaulino marked this conversation as resolved.

 }

 if let Some(us) = $self_opt {
 let mut inner = us.inner.lock().unwrap();
 inner.pending_events.drain(..num_events);
 inner.is_processing_pending_events = false;
 if !inner.pending_events.is_empty() {
 // If there's more events to process, go ahead and do so.
 continue;
 }
 }
 break;
Comment thread
wpaulino marked this conversation as resolved.

Comment thread
TheBlueMatt marked this conversation as resolved.

 }
	}
}
pub(super) use _process_events_body as process_events_body;

impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
	/// For lockorder enforcement purposes, we need to have a single site which constructs the
	/// `inner` mutex, otherwise cases where we lock two monitors at the same time (eg in our
Expand DownExpand Up@@ -1179,6 +1211,7 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
 payment_preimages: HashMap::new(),
 pending_monitor_events: Vec::new(),
 pending_events: Vec::new(),
 is_processing_pending_events: false,

 onchain_events_awaiting_threshold_conf: Vec::new(),
 outputs_to_watch,
Expand DownExpand Up@@ -1306,16 +1339,41 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
 self.inner.lock().unwrap().get_and_clear_pending_monitor_events()
	}

	/// Gets the list of pending events which were generated by previous actions, clearing the list
	/// in the process.
	/// Processes [`SpendableOutputs`] events produced from each [`ChannelMonitor`] upon maturity.
	///
	/// For channels featuring anchor outputs, this method will also process [`BumpTransaction`]
	/// events produced from each [`ChannelMonitor`] while there is a balance to claim onchain
	/// within each channel. As the confirmation of a commitment transaction may be critical to the
	/// safety of funds, we recommend invoking this every 30 seconds, or lower if running in an
	/// environment with spotty connections, like on mobile.
	///
	/// This is called by the [`EventsProvider::process_pending_events`] implementation for
	/// [`ChainMonitor`].
	/// An [`EventHandler`] may safely call back to the provider, though this shouldn't be needed in
	/// order to handle these events.
	///
	/// [`SpendableOutputs`]: crate::events::Event::SpendableOutputs
	/// [`BumpTransaction`]: crate::events::Event::BumpTransaction
	pub fn process_pending_events<H: Deref>(&self, handler: &H) where H::Target: EventHandler {
 let mut ev;
 process_events_body!(Some(self), ev, handler.handle_event(ev));
	}

	/// Processes any events asynchronously.
	///
	/// [`EventsProvider::process_pending_events`]: crate::events::EventsProvider::process_pending_events
	/// [`ChainMonitor`]: crate::chain::chainmonitor::ChainMonitor
	/// See [`Self::process_pending_events`] for more information.
	pub async fn process_pending_events_async<Future: core::future::Future, H: Fn(Event) -> Future>(
 &self, handler: &H
	) {
 let mut ev;
 process_events_body!(Some(self), ev, { handler(ev).await });
	}

	#[cfg(test)]
	pub fn get_and_clear_pending_events(&self) -> Vec<Event> {
Comment thread
TheBlueMatt marked this conversation as resolved.

 self.inner.lock().unwrap().get_and_clear_pending_events()
 let mut ret = Vec::new();
 let mut lck = self.inner.lock().unwrap();
 mem::swap(&mut ret, &mut lck.pending_events);
 ret.append(&mut lck.get_repeated_events());
 ret
	}

	pub(crate) fn get_min_seen_secret(&self) -> u64 {
Expand DownExpand Up@@ -2531,10 +2589,13 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitorImpl<Signer> {
 ret
	}

	pub fn get_and_clear_pending_events(&mut self) -> Vec<Event> {
 let mut ret = Vec::new();
 mem::swap(&mut ret, &mut self.pending_events);
Comment thread
TheBlueMatt marked this conversation as resolved.

 for (claim_id, claim_event) in self.onchain_tx_handler.get_and_clear_pending_claim_events().drain(..) {
	/// Gets the set of events that are repeated regularly (e.g. those which RBF bump
	/// transactions). We're okay if we lose these on restart as they'll be regenerated for us at
	/// some regular interval via [`ChannelMonitor::rebroadcast_pending_claims`].
	pub(super) fn get_repeated_events(&mut self) -> Vec<Event> {
 let pending_claim_events = self.onchain_tx_handler.get_and_clear_pending_claim_events();
 let mut ret = Vec::with_capacity(pending_claim_events.len());
 for (claim_id, claim_event) in pending_claim_events {
 match claim_event {
 ClaimEvent::BumpCommitment {
 package_target_feerate_sat_per_1000_weight, commitment_tx, anchor_output_idx,
Expand DownExpand Up@@ -4096,6 +4157,7 @@ impl<'a, 'b, ES: EntropySource, SP: SignerProvider> ReadableArgs<(&'a ES, &'b SP
 payment_preimages,
 pending_monitor_events: pending_monitor_events.unwrap(),
 pending_events,
 is_processing_pending_events: false,

 onchain_events_awaiting_threshold_conf,
 outputs_to_watch,
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
Don't drop ChannelMonitor Events until they're processed#2369

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.

 Sign up for GitHub

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

 Merged

wpaulino
merged 1 commit into

from

Jul 10, 2023
 Merged


Don't drop ChannelMonitor Events until they're processed
#2369
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


1 commit


Select commit


File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


19 changes: 8 additions & 11 deletions
lightning/src/chain/chainmonitor.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -520,12 +520,13 @@ where C::Target: chain::Filter,
	pub async fn process_pending_events_async<Future: core::future::Future, H: Fn(Event) -> Future>(
 &self, handler: H
	) {
 let mut pending_events = Vec::new();
 for monitor_state in self.monitors.read().unwrap().values() {
 pending_events.append(&mut monitor_state.monitor.get_and_clear_pending_events());
 }
 for event in pending_events {
 handler(event).await;
 // Sadly we can't hold the monitors read lock through an async call. Thus we have to do a
 // crazy dance to process a monitor's events then only remove them once we've done so.
 let mons_to_process = self.monitors.read().unwrap().keys().cloned().collect::<Vec<_>>();
 for funding_txo in mons_to_process {
 let mut ev;
 super::channelmonitor::process_events_body!(
 self.monitors.read().unwrap().get(&funding_txo).map(|m| &m.monitor), ev, handler(ev).await);
@alecchendevalecchendevJul 6, 2023

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

Will this first argument ever be None?
@TheBlueMattTheBlueMattJul 7, 2023

Copy link


Copy Markdown

CollaboratorAuthor
Choose a reason for hiding this comment

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

Currently I don't think so, but in the future we probably want to support removing monitors after they're done with all their processing (and probably will do so automatically). Thus, we should handle the case where the monitor has dissapeared on us (we don't hold a lock through the loop anyway, so its good practice to not rely on any assumptions about the underlying data changing).
 }
	}

Expand DownExpand Up@@ -796,12 +797,8 @@ impl<ChannelSigner: WriteableEcdsaChannelSigner, C: Deref, T: Deref, F: Deref, L
	/// [`SpendableOutputs`]: events::Event::SpendableOutputs
	/// [`BumpTransaction`]: events::Event::BumpTransaction
	fn process_pending_events<H: Deref>(&self, handler: H) where H::Target: EventHandler {
 let mut pending_events = Vec::new();
 for monitor_state in self.monitors.read().unwrap().values() {
 pending_events.append(&mut monitor_state.monitor.get_and_clear_pending_events());
 }
 for event in pending_events {
 handler.handle_event(event);
 monitor_state.monitor.process_pending_events(&handler);
 }
	}
}
Expand Down

100 changes: 81 additions & 19 deletions
lightning/src/chain/channelmonitor.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -49,7 +49,7 @@ use crate::chain::Filter;
use crate::util::logger::Logger;
use crate::util::ser::{Readable, ReadableArgs, RequiredWrapper, MaybeReadable, UpgradableRequired, Writer, Writeable, U48};
use crate::util::byte_utils;
use crate::events::Event;
use crate::events::{Event, EventHandler};
use crate::events::bump_transaction::{AnchorDescriptor, HTLCDescriptor, BumpTransactionEvent};

use crate::prelude::*;
Expand DownExpand Up@@ -738,11 +738,6 @@ impl Readable for IrrevocablyResolvedHTLC {
/// You MUST ensure that no ChannelMonitors for a given channel anywhere contain out-of-date
/// information and are actively monitoring the chain.
///
/// Pending Events or updated HTLCs which have not yet been read out by
/// get_and_clear_pending_monitor_events or get_and_clear_pending_events are serialized to disk and
/// reloaded at deserialize-time. Thus, you must ensure that, when handling events, all events
/// gotten are fully handled before re-serializing the new state.
///
/// Note that the deserializer is only implemented for (BlockHash, ChannelMonitor), which
/// tells you the last block hash which was block_connect()ed. You MUST rescan any blocks along
/// the "reorg path" (ie disconnecting blocks until you find a common ancestor from both the
Expand All@@ -752,7 +747,7 @@ pub struct ChannelMonitor<Signer: WriteableEcdsaChannelSigner> {
	#[cfg(test)]
	pub(crate) inner: Mutex<ChannelMonitorImpl<Signer>>,
	#[cfg(not(test))]
	inner: Mutex<ChannelMonitorImpl<Signer>>,
pub(super) inner: Mutex<ChannelMonitorImpl<Signer>>,
}

#[derive(PartialEq)]
Expand DownExpand Up@@ -829,7 +824,8 @@ pub(crate) struct ChannelMonitorImpl<Signer: WriteableEcdsaChannelSigner> {
	// we further MUST NOT generate events during block/transaction-disconnection.
	pending_monitor_events: Vec<MonitorEvent>,

	pending_events: Vec<Event>,
	pub(super) pending_events: Vec<Event>,
	pub(super) is_processing_pending_events: bool,

	// Used to track on-chain events (i.e., transactions part of channels confirmed on chain) on
	// which to take actions once they reach enough confirmations. Each entry includes the
Expand DownExpand Up@@ -1088,6 +1084,42 @@ impl<Signer: WriteableEcdsaChannelSigner> Writeable for ChannelMonitorImpl<Signe
	}
}

macro_rules! _process_events_body {
	($self_opt: expr, $event_to_handle: expr, $handle_event: expr) => {
 loop {
 let (pending_events, repeated_events);
 if let Some(us) = $self_opt {
 let mut inner = us.inner.lock().unwrap();
 if inner.is_processing_pending_events {
 break;
 }
 inner.is_processing_pending_events = true;

 pending_events = inner.pending_events.clone();
 repeated_events = inner.get_repeated_events();
 } else { break; }
 let num_events = pending_events.len();

 for event in pending_events.into_iter().chain(repeated_events.into_iter()) {
 $event_to_handle = event;
 $handle_event;
Comment thread
wpaulino marked this conversation as resolved.

 }

 if let Some(us) = $self_opt {
 let mut inner = us.inner.lock().unwrap();
 inner.pending_events.drain(..num_events);
 inner.is_processing_pending_events = false;
 if !inner.pending_events.is_empty() {
 // If there's more events to process, go ahead and do so.
 continue;
 }
 }
 break;
Comment thread
wpaulino marked this conversation as resolved.

Comment thread
TheBlueMatt marked this conversation as resolved.

 }
	}
}
pub(super) use _process_events_body as process_events_body;

impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
	/// For lockorder enforcement purposes, we need to have a single site which constructs the
	/// `inner` mutex, otherwise cases where we lock two monitors at the same time (eg in our
Expand DownExpand Up@@ -1179,6 +1211,7 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
 payment_preimages: HashMap::new(),
 pending_monitor_events: Vec::new(),
 pending_events: Vec::new(),
 is_processing_pending_events: false,

 onchain_events_awaiting_threshold_conf: Vec::new(),
 outputs_to_watch,
Expand DownExpand Up@@ -1306,16 +1339,41 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitor<Signer> {
 self.inner.lock().unwrap().get_and_clear_pending_monitor_events()
	}

	/// Gets the list of pending events which were generated by previous actions, clearing the list
	/// in the process.
	/// Processes [`SpendableOutputs`] events produced from each [`ChannelMonitor`] upon maturity.
	///
	/// For channels featuring anchor outputs, this method will also process [`BumpTransaction`]
	/// events produced from each [`ChannelMonitor`] while there is a balance to claim onchain
	/// within each channel. As the confirmation of a commitment transaction may be critical to the
	/// safety of funds, we recommend invoking this every 30 seconds, or lower if running in an
	/// environment with spotty connections, like on mobile.
	///
	/// This is called by the [`EventsProvider::process_pending_events`] implementation for
	/// [`ChainMonitor`].
	/// An [`EventHandler`] may safely call back to the provider, though this shouldn't be needed in
	/// order to handle these events.
	///
	/// [`SpendableOutputs`]: crate::events::Event::SpendableOutputs
	/// [`BumpTransaction`]: crate::events::Event::BumpTransaction
	pub fn process_pending_events<H: Deref>(&self, handler: &H) where H::Target: EventHandler {
 let mut ev;
 process_events_body!(Some(self), ev, handler.handle_event(ev));
	}

	/// Processes any events asynchronously.
	///
	/// [`EventsProvider::process_pending_events`]: crate::events::EventsProvider::process_pending_events
	/// [`ChainMonitor`]: crate::chain::chainmonitor::ChainMonitor
	/// See [`Self::process_pending_events`] for more information.
	pub async fn process_pending_events_async<Future: core::future::Future, H: Fn(Event) -> Future>(
 &self, handler: &H
	) {
 let mut ev;
 process_events_body!(Some(self), ev, { handler(ev).await });
	}

	#[cfg(test)]
	pub fn get_and_clear_pending_events(&self) -> Vec<Event> {
Comment thread
TheBlueMatt marked this conversation as resolved.

 self.inner.lock().unwrap().get_and_clear_pending_events()
 let mut ret = Vec::new();
 let mut lck = self.inner.lock().unwrap();
 mem::swap(&mut ret, &mut lck.pending_events);
 ret.append(&mut lck.get_repeated_events());
 ret
	}

	pub(crate) fn get_min_seen_secret(&self) -> u64 {
Expand DownExpand Up@@ -2531,10 +2589,13 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitorImpl<Signer> {
 ret
	}

	pub fn get_and_clear_pending_events(&mut self) -> Vec<Event> {
 let mut ret = Vec::new();
 mem::swap(&mut ret, &mut self.pending_events);
Comment thread
TheBlueMatt marked this conversation as resolved.

 for (claim_id, claim_event) in self.onchain_tx_handler.get_and_clear_pending_claim_events().drain(..) {
	/// Gets the set of events that are repeated regularly (e.g. those which RBF bump
	/// transactions). We're okay if we lose these on restart as they'll be regenerated for us at
	/// some regular interval via [`ChannelMonitor::rebroadcast_pending_claims`].
	pub(super) fn get_repeated_events(&mut self) -> Vec<Event> {
 let pending_claim_events = self.onchain_tx_handler.get_and_clear_pending_claim_events();
 let mut ret = Vec::with_capacity(pending_claim_events.len());
 for (claim_id, claim_event) in pending_claim_events {
 match claim_event {
 ClaimEvent::BumpCommitment {
 package_target_feerate_sat_per_1000_weight, commitment_tx, anchor_output_idx,
Expand DownExpand Up@@ -4096,6 +4157,7 @@ impl<'a, 'b, ES: EntropySource, SP: SignerProvider> ReadableArgs<(&'a ES, &'b SP
 payment_preimages,
 pending_monitor_events: pending_monitor_events.unwrap(),
 pending_events,
 is_processing_pending_events: false,

 onchain_events_awaiting_threshold_conf,
 outputs_to_watch,
Expand Down