Wake background-processor from ChainMonitor on new blocks
#3033
Conversation
|
Would this have adverse effects if someone's on regtest and mines 100+ blocks at once? Or testnet blockstorms. That's the only reason I could see we'd want more precise notifications for pending events. |
TheBlueMatt
force-pushed
the
2024-04-notify-bp-on-blocks
branch
from
0348de2
to
8f4a107
Compare
|
It shouldn't - if we're too slow the BP won't always loop 100 times but rather will ensure it loops at least once after the last notify. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #3033 +/- ##
==========================================
- Coverage 89.14% 89.13% -0.02%
==========================================
Files 118 118
Lines 97850 97972 +122
Branches 97850 97972 +122
==========================================
+ Hits 87230 87325 +95
- Misses 8376 8400 +24
- Partials 2244 2247 +3 ☔ View full report in Codecov by Sentry. |
| @@ -738,6 +740,8 @@ where | |||
| monitor.block_connected( | |||
| header, txdata, height, &*self.broadcaster, &*self.fee_estimator, &self.logger) | |||
| }); | |||
| // Assume we may have some new events and wake the event processor | |||
There was a problem hiding this comment.
usually, i see that we notify event_notifier just after publishing the event to chainmonitor::pending_monitor_events.
but i see that we don't do so for channelmonitor::pending_monitor_events when we push new actionable events and we don't have access to event_notifier in channelmonitor.
Can you help me understand this pattern?
There was a problem hiding this comment.
Right, we don't have access to the event_notifier so we just assume there may be new events and wake. Not much reason to worry too much about it, a BP loop is pretty cheap so having to do a few extra won't kill us.
When we receive a new block we may generate `Event::SpendableOutputs` in `ChannelMonitor`s which then need to be processed by the background processor. While it will do so eventually when its normal loop goes around, this may cause user tests to be delayed in finding events, so we should notify the BP immediately to wake it on new blocks. We implement that here, unconditionally notifying the `background-processor` whenever we receive a new block or confirmed transactions.
TheBlueMatt
force-pushed
the
2024-04-notify-bp-on-blocks
branch
from
8f4a107
to
021979b
Compare
…fy-bp-on-blocks Wake `background-processor` from `ChainMonitor` on new blocks
When we receive a new block we may generate
Event::SpendableOutputsinChannelMonitors which then need to be processed by the background processor. While it will do so eventually when its normal loop goes around, this may cause user tests to be delayed in finding events, so we should notify the BP immediately to wake it on new blocks.We implement that here, unconditionally notifying the
background-processorwhenever we receive a new block or confirmed transactions.