Skip to content

Conversation

@TheBlueMatt
Copy link
Collaborator

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 move to instead using the automated `add_logging`
proc-macro to require that `OutboundPayment` functions receive a
`WithContext` logger, appropriately setting (especially) the
`payment_hash` as we do so.

Fixes #4307

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.

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Jan 25, 2026

👋 Thanks for assigning @wpaulino as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@TheBlueMatt TheBlueMatt force-pushed the 2026-01-decode-log-payment-hash branch from 3ca1fbd to ad93b8d Compare January 25, 2026 16:51
@codecov
Copy link

codecov bot commented Jan 25, 2026

Codecov Report

❌ Patch coverage is 88.26087% with 27 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.09%. Comparing base (7fe3268) to head (91e4354).

Files with missing lines Patch % Lines
lightning/src/ln/outbound_payment.rs 85.40% 12 Missing and 8 partials ⚠️
lightning/src/ln/channelmanager.rs 86.53% 7 Missing ⚠️
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     
Flag Coverage Δ
tests 86.09% <88.26%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

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

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@TheBlueMatt
Copy link
Collaborator Author

Planning to backport to 0.2 in #4344

wpaulino
wpaulino previously approved these changes Jan 26, 2026
Copy link
Contributor

@wpaulino wpaulino left a 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.

@ldk-reviews-bot
Copy link

👋 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.

@ldk-reviews-bot
Copy link

✅ Added second reviewer: @valentinewallace

@TheBlueMatt
Copy link
Collaborator Author

I'm not really a fan of the hidden logger argument.

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 ChannelManager).

Copy link
Contributor

@valentinewallace valentinewallace left a 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.

Copy link
Contributor

@joostjager joostjager left a 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.

@TheBlueMatt TheBlueMatt force-pushed the 2026-01-decode-log-payment-hash branch from 5759a10 to f50c6a6 Compare January 27, 2026 20:08
@TheBlueMatt
Copy link
Collaborator Author

Alrighty, explicit loggers it is.

@TheBlueMatt TheBlueMatt force-pushed the 2026-01-decode-log-payment-hash branch 3 times, most recently from 8508cf3 to 5e5c54a Compare January 27, 2026 20:13
wpaulino
wpaulino previously approved these changes Jan 28, 2026
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.
@TheBlueMatt
Copy link
Collaborator Author

Had to rebase for a trivial conflict.

Copy link
Contributor

@valentinewallace valentinewallace left a 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);

Copy link
Contributor

Choose a reason for hiding this comment

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

nit: spurious newline

// 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));
Copy link
Contributor

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

Copy link
Collaborator Author

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,
Copy link
Contributor

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

Comment on lines +326 to +328
if self.payment_id.is_some() {
record.payment_id = self.payment_id;
}
Copy link
Contributor

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

decode_onion_failure loggers dont have a payment hash

5 participants