Skip to content
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

Add peer_id and channel_id explicitly to log records #2314

Merged
merged 9 commits into from
Dec 2, 2023

Conversation

henghonglee
Copy link
Contributor

@henghonglee henghonglee commented May 23, 2023

fixes #2292

This change adds explicit spots in the log Record struct for peer_id and channel_id
This makes the logs much more structured and ensure that they are not forgetten
during implementation

@codecov-commenter
Copy link

codecov-commenter commented May 23, 2023

Codecov Report

Attention: 115 lines in your changes are missing coverage. Please review.

Comparison is base (74bc9e2) 88.64% compared to head (35b7688) 88.51%.

❗ Current head 35b7688 differs from pull request most recent head e21a500. Consider uploading reports for the commit e21a500 to get more accurate results

Files Patch % Lines
lightning/src/ln/peer_handler.rs 14.49% 50 Missing and 9 partials ⚠️
lightning/src/ln/channelmanager.rs 78.00% 23 Missing and 10 partials ⚠️
lightning/src/chain/chainmonitor.rs 52.77% 7 Missing and 10 partials ⚠️
lightning/src/chain/channelmonitor.rs 93.33% 5 Missing ⚠️
lightning/src/ln/channel.rs 95.00% 0 Missing and 1 partial ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2314      +/-   ##
==========================================
- Coverage   88.64%   88.51%   -0.13%     
==========================================
  Files         115      113       -2     
  Lines       90023    89550     -473     
  Branches    90023    89550     -473     
==========================================
- Hits        79801    79266     -535     
- Misses       7825     7904      +79     
+ Partials     2397     2380      -17     

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

@henghonglee henghonglee force-pushed the issue-2292 branch 3 times, most recently from bdf0de5 to 2c69caf Compare May 24, 2023 22:00
@henghonglee henghonglee marked this pull request as ready for review May 24, 2023 22:00
@henghonglee henghonglee force-pushed the issue-2292 branch 4 times, most recently from 8bb0617 to 8748f91 Compare May 24, 2023 22:09
Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

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

Thanks for working on this! Sorry for the delay in getting back to you.

lightning-background-processor/src/lib.rs Outdated Show resolved Hide resolved
lightning/src/util/logger.rs Outdated Show resolved Hide resolved
lightning-invoice/src/utils.rs Outdated Show resolved Hide resolved
lightning/src/chain/channelmonitor.rs Outdated Show resolved Hide resolved
@henghonglee henghonglee closed this Jun 1, 2023
@henghonglee henghonglee force-pushed the issue-2292 branch 2 times, most recently from 377116a to 32eb894 Compare June 1, 2023 09:49
@henghonglee henghonglee reopened this Jun 1, 2023
@henghonglee henghonglee force-pushed the issue-2292 branch 4 times, most recently from 8515d27 to 4f941bc Compare June 1, 2023 11:41
@henghonglee
Copy link
Contributor Author

henghonglee commented Jun 1, 2023

Probably a crude attempt right now, defining the mappings at the top of the files themselves. would prefer to do all the mapping up front in the mod.rs files or elsewhere and also have a sensible default.

just putting it out there, not feeling too strongly abt this approach yet

lightning/src/ln/channel.rs Outdated Show resolved Hide resolved
lightning/src/util/macro_logger.rs Outdated Show resolved Hide resolved
@TheBlueMatt
Copy link
Collaborator

This patch works for me, so I think we should go this kind of direction (with different uses depending on the file for context-containing versions of the log macros):

diff --git a/lightning/src/chain/package.rs b/lightning/src/chain/package.rs
index 4604a164c..6c2c9c706 100644
--- a/lightning/src/chain/package.rs
+++ b/lightning/src/chain/package.rs
@@ -44,4 +44,6 @@ use bitcoin::{PackedLockTime, Sequence, Witness};
 use super::chaininterface::LowerBoundedFeeEstimator;
 
+use crate::util::macro_logger::log_warn;
+
 const MAX_ALLOC_SIZE: usize = 64*1024;
 
diff --git a/lightning/src/ln/channel.rs b/lightning/src/ln/channel.rs
index 99b3c1691..fc9439efa 100644
--- a/lightning/src/ln/channel.rs
+++ b/lightning/src/ln/channel.rs
@@ -53,4 +53,6 @@ use crate::sync::Mutex;
 use bitcoin::hashes::hex::ToHex;
 
+use crate::util::macro_logger::log_warn;
+
 #[cfg(test)]
 pub struct ChannelValueStat {
diff --git a/lightning/src/routing/scoring.rs b/lightning/src/routing/scoring.rs
index 235b1a148..56ebceefb 100644
--- a/lightning/src/routing/scoring.rs
+++ b/lightning/src/routing/scoring.rs
@@ -62,4 +62,5 @@ use crate::routing::router::Path;
 use crate::util::ser::{Readable, ReadableArgs, Writeable, Writer};
 use crate::util::logger::Logger;
+use crate::util::macro_logger::log_warn;
 use crate::util::time::Time;
 
diff --git a/lightning/src/util/macro_logger.rs b/lightning/src/util/macro_logger.rs
index 8742e8e84..42d74767b 100644
--- a/lightning/src/util/macro_logger.rs
+++ b/lightning/src/util/macro_logger.rs
@@ -199,5 +199,5 @@ macro_rules! log_error {
 /// Log at the `WARN` level.
 #[macro_export]
-macro_rules! log_warn {
+macro_rules! _log_warn {
        ($logger: expr, $($arg:tt)*) => (
                $crate::log_given_level!($logger, $crate::util::logger::Level::Warn, $($arg)*);
@@ -205,4 +205,6 @@ macro_rules! log_warn {
 }
 
+pub use _log_warn as log_warn;
+
 /// Log at the `INFO` level.
 #[macro_export]

@henghonglee henghonglee force-pushed the issue-2292 branch 6 times, most recently from 062c703 to da9f77c Compare June 6, 2023 04:49
@jkczyz
Copy link
Contributor

jkczyz commented Nov 24, 2023

Rebased on main from a few days back. Looks like there is some more recent conflicts to resolve. All handle those and will need to go through ChannelManager a little closer.

Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

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

Just skimmed, but basically LGTM. We might as well land this.

@@ -799,12 +808,16 @@ where C::Target: chain::Filter,
}
};
if let ChannelMonitorUpdateStatus::UnrecoverableError = ret {
let logger = WithChannelMonitor::from(
Copy link
Collaborator

Choose a reason for hiding this comment

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

Lets move this code lock into the Some match and drop the unwrap?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yup, refactored the code slightly to allow for this.

@@ -1125,6 +1125,30 @@ macro_rules! _process_events_body {
}
pub(super) use _process_events_body as process_events_body;

pub(crate) struct WithChannelMonitor<'a, L: Deref> where L::Target: Logger {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Would be nice to move some of the pub(crate) methods on ChannelMonitor to take a WithChannelMonitor explicitly, rather than a generic Logger, so that we enforce that its called correctly. It can happen later, though. Same in channel.rs, but the channel type.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, I tend to agree that we should make this more enforceable. Ideally, we can just have those structs store a wrapped Logger instead of passing one and relying on the caller to do the wrapping. Though, I think that may mean introducing a lifetime parameter.

But if instead we make the types explicit on pub(crate) methods, then we may avoid some redundant wrapping. Let me take a look.

@jkczyz
Copy link
Contributor

jkczyz commented Nov 28, 2023

Pushed a few fixups and I think an amended commit that I hadn't pushed last week.

@jkczyz
Copy link
Contributor

jkczyz commented Nov 28, 2023

Pushed a few fixups and I think an amended commit that I hadn't pushed last week.

Ugh, also a rebase apparently 😞

@jkczyz
Copy link
Contributor

jkczyz commented Nov 28, 2023

Ugh, also a rebase apparently 😞

Just a bad push, actually. This should be the right diff: https://github.com/lightningdevkit/rust-lightning/compare/35b768825950c81bee510d2a80cd19c926b817a6..189ea78eca81e86e3be9d561eaf005e669a7d51e

@jkczyz
Copy link
Contributor

jkczyz commented Nov 29, 2023

@TheBlueMatt Looks like I'll need to rebase this again.

@TheBlueMatt
Copy link
Collaborator

I'm kinda ready to land whenever you want to squash and rebase, will just take me an hour to go back over it and hit the button.

@TheBlueMatt
Copy link
Collaborator

Ugh, needs rebase again lol

henghonglee and others added 9 commits December 1, 2023 11:30
Instead of passing a reference to a Record, pass the Logger an owned
Record so that it can be decorated with semantic context.
Include optional peer and channel ids to logger::Record. This will be
used by wrappers around Logger in order to provide more context (e.g.,
the peer that sent a message, the channel an operation is pertaining to,
etc.). Implementations of Logger can include this as metadata to aid in
searching logs.
Using a decorator pattern, add peer_id and channel_id to Record
stored on Logger.
Move the handling of ChannelMonitorUpdateStatus::UnrecoverableError to
the point of error to avoid needing an unwrap later when re-wrapping the
logger.
@jkczyz
Copy link
Contributor

jkczyz commented Dec 1, 2023

Ugh, needs rebase again lol

Rebased!

Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

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

Some followups, but we need to just land this so that we can move on.

&self, module: &str, peer_id: Option<PublicKey>, channel_id: Option<ChannelId>, count: usize
) {
let context_entries = self.context.lock().unwrap();
let l: usize = context_entries.iter()
Copy link
Collaborator

Choose a reason for hiding this comment

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

Its a hashmap, we can look up, rather than iterate + count.

}
}

impl<'a, 'b, L: Deref> WithChannelContext<'a, L>
Copy link
Collaborator

Choose a reason for hiding this comment

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

I believe 'b can be elided.

}
}

impl<'a, 'b, L: Deref> WithChannelMonitor<'a, L> where L::Target: Logger {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I believe 'b can be elided.

ChannelMonitorUpdateStatus::UnrecoverableError => {
// Take the monitors lock for writing so that we poison it and any future
// operations going forward fail immediately.
core::mem::drop(monitors);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Because this no longer drops the lock itself, we'll just hang on the next line rather than actually panicking.

@TheBlueMatt TheBlueMatt merged commit 6b43153 into lightningdevkit:main Dec 2, 2023
15 checks passed
wpaulino added a commit that referenced this pull request Dec 4, 2023
@jkczyz jkczyz mentioned this pull request Dec 6, 2023
TheBlueMatt added a commit that referenced this pull request Dec 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add channel id/peer id to Logger's Record
6 participants