-
Notifications
You must be signed in to change notification settings - Fork 433
Require WithContext log wrappers on OutboundPayments calls and pass payment hashes
#4342
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
base: main
Are you sure you want to change the base?
Require WithContext log wrappers on OutboundPayments calls and pass payment hashes
#4342
Conversation
|
👋 Thanks for assigning @wpaulino as a reviewer! |
3ca1fbd to
ad93b8d
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4342 +/- ##
=========================================
+ Coverage 0 86.09% +86.09%
=========================================
Files 0 156 +156
Lines 0 102526 +102526
Branches 0 102526 +102526
=========================================
+ Hits 0 88273 +88273
- Misses 0 11757 +11757
- Partials 0 2496 +2496
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Planning to backport to 0.2 in #4344 |
wpaulino
left a comment
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.
Code LGTM though I'm not really a fan of the hidden logger argument.
|
👋 The first review has been submitted! Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer. |
|
✅ Added second reviewer: @valentinewallace |
I could go either way. It seems like an easy way to ensure we always have the logger which will make @joostjager happy, and in this case its fairly straightforward (because we're not trying to automate passing the logger from |
valentinewallace
left a comment
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.
I'm not really into this juice vs squeeze ratio. I think @joostjager should take a look since it's supposed to make him happy :) If it really does, I guess it's fine.
Mentioned to Matt offline but Claude pointed out that the visit-mut syn feature allows removing ~all the boilerplate.
ad93b8d to
5759a10
Compare
joostjager
left a comment
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.
Appreciate the attempt, but I don't think this is the right direction. The macro adds a layer of complexity, and the hidden logger argument that gets silently injected into every self.*() call isn't very intuitive. I agree with @wpaulino and @valentinewallace's hesitation.
My preference would still be to keep exploring something similar to what the tracing crate does with the context. For no-std the developer experience might not be optimal, but I still think that is a reasonable trade-off.
If that is unacceptable, I think we're better off sticking with explicit logger parameters and types. At least the code does what it says.
5759a10 to
f50c6a6
Compare
|
Alrighty, explicit loggers it is. |
8508cf3 to
5e5c54a
Compare
In `ChannelMonitor` logging, we often wrap a logger with `WithChannelMonitor` to automatically include metadata in our structured logging. That's great, except having too many logger wrapping types flying around makes for less compatibility if we have methods that want to require a wrapped-logger. Here we change the `WithChannelMonitor` "constructors" to actually return a `WithContext` instead, making things more consistent.
In much of LDK we pass around `Logger` objects both to avoid having to `Clone` `Logger` `Deref`s (soon to only be `Logger`s) and to allow us to set context with a wrapper such that any log calls on that wrapper get additional useful metadata in them. Sadly, when we added a `Logger` type to `OutboundPayments` we broke the ability to do the second thing - payment information logged directly or indirectly via logic in the `OutboundPayments` has no context making log-searching rather challenging. Here we fix this by retunring to passing loggers explicitly to `OutboundPayments` methods that need them, specifically requiring `WithContext` wrappers to ensure the callsite sets appropriate context on the logger. Fixes lightningdevkit#4307
While `PaymentHash`es are great for searching logs, in the case of BOLT 12 the hash isn't selected until well into the payment process. Thus, its important that we allow for filtering by `PaymentId` as well to ensure payment-related logs are always reliably searchable.
5e5c54a to
91e4354
Compare
|
Had to rebase for a trivial conflict. |
valentinewallace
left a comment
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.
LGTM. I think CI is still sad
|
|
||
| fn abandon_payment_with_reason(&self, payment_id: PaymentId, reason: PaymentFailureReason) { | ||
| let _persistence_guard = PersistenceNotifierGuard::notify_on_drop(self); | ||
|
|
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.
nit: spurious newline
lightning/src/ln/channelmanager.rs
Outdated
| // being fully configured. See the docs for `ChannelManagerReadArgs` for more. | ||
| match source { | ||
| HTLCSource::OutboundRoute { ref path, ref session_priv, ref payment_id, .. } => { | ||
| let logger = WithContext::from(&self.logger, None, None, Some(*payment_hash)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might make sense to use the first-hop channel_id/peer here, similarly for claims below
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.
Oh it is done but in the last commit.
| &prev_hop_data, | ||
| "HTLC already forwarded to the outbound edge", | ||
| &args.logger, | ||
| &&logger, |
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.
nit: here and some other places below don't really fit into this commit which is specific to outbound_payments calls
| if self.payment_id.is_some() { | ||
| record.payment_id = self.payment_id; | ||
| } |
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.
Somewhat pre-existing, but could it be worth checking that we're not overriding an already set field with a different field here?
I believe the first three commits can/should be backported to 0.2. Ideally we'd also backports a variant to 0.1 to fix #4307 there but I'm not really sure its quite worth it to write a whole new version just for 0.1.