-
Notifications
You must be signed in to change notification settings - Fork 385
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Log when a channel is closed on startup due to stale ChannelManager #1029
Log when a channel is closed on startup due to stale ChannelManager #1029
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1029 +/- ##
==========================================
+ Coverage 90.80% 92.37% +1.56%
==========================================
Files 60 61 +1
Lines 31460 40551 +9091
==========================================
+ Hits 28568 37459 +8891
- Misses 2892 3092 +200
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 05de81b
This is one of the riskiest parts of our API from the perspective of accidental force-closes - if users delay persisting the ChannelManager much at all after a ChannelMonitor we may hit a force-close after restart. The fact that we don't log at all when this happens is criminal.
It is easy for users to have a bug where they drop a `BackgroundProcessor` immediately, causing it to start and then immediately stop. Instead, add a `#[must_use]` tag to provide a compiler warning for such instances.
05de81b
to
5307b5e
Compare
Pushed a trivial wording clarification as suggested by @ariard. Compared to ACKs full diff is below, will merge after CI:
|
This is one of the riskiest parts of our API from the perspective
of accidental force-closes - if users delay persisting the
ChannelManager much at all after a ChannelMonitor we may hit a
force-close after restart.
The fact that we don't log at all when this happens is criminal.