[0.2] Backports and cut 0.2.1#4344
Merged
TheBlueMatt merged 13 commits intolightningdevkit:0.2from Jan 30, 2026
Merged
Conversation
|
👋 Thanks for assigning @valentinewallace as a reviewer! |
f455df3 to
9ad9bf4
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## 0.2 #4344 +/- ##
==========================================
- Coverage 88.87% 86.11% -2.77%
==========================================
Files 180 156 -24
Lines 138117 99889 -38228
Branches 138117 99889 -38228
==========================================
- Hits 122752 86018 -36734
+ Misses 12543 11378 -1165
+ Partials 2822 2493 -329
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:
|
4bced05 to
1ce59e5
Compare
1ce59e5 to
b035089
Compare
This was referenced Jan 26, 2026
b035089 to
6fdac57
Compare
`AttributionData` is a part of the public `UpdateFulfillHTLC` and `UpdateFailHTLC` messages, but its not actually `pub`. Yet again re-exports bite us and leave us with a broken public API - we ended up accidentally sealing `AttributionData`. Instead, here, we just make `onion_utils` `pub` so that we avoid making the same mistake in the future. Note that this still leaves us with arather useless public `AttributionData` API - it can't be created, updated, or decoded, it can only be serialized and deserialized, but at least it exists. Backport of bd57823 Conflicts resolved in: * lightning/src/ln/onion_utils.rs semver-breaking `pub use` removal dropped in: * lightning/src/ln/mod.rs
Backport of 6578b88
The next backport commit requires this and it was done upstream in 173481f, which we partially backport here.
In 20877b3 we added a `debug_assert`ion to validate that if we call `maybe_free_holding_cell_htlcs` and it doesn't manage to generate a new commitment (implying `!can_generate_new_commitment()`) that we don't have any HTLCs to fail, but there was no reason for that, and its reachable. Here we simply remove the spurious debug assertion and add a test that exercises it. Backport of b524b9b
Previously, `lightning-background-processor`'s `Selector` would poll all other futures *before* finally polling the sleeper and returning the `exit` flag if it's ready. This could lead to scenarios where we infinitely keep processing background events and never respect the `exit` flag, as long as any of other futures keep being ready. Here, we instead bias the `Selector` to always *first* poll the sleeper future, and hence have us act on the `exit` flag immediately if is set. Backport of 9c0ca26
Electrum's `blockchain.scripthash.get_history` will return the *confirmed* history for any scripthash, but will then also append any matching entries from the mempool, with respective `height` fields set to 0 or -1 (depending on whether all inputs are confirmed or not). Unfortunately we previously only included a filter for confirmed `get_history` entries in the watched output case, and forgot to add such a check also when checking for watched transactions. This would have us treat the entry as confirmed, then failing on the `get_merkle` step which of course couldn't prove block inclusion. Here we simply fix this omission and skip entries that are still unconfirmed (e.g., unconfirmed funding transactions from 0conf channels). Signed-off-by: Elias Rohrer <dev@tnull.de> Backport of cc1eb16
a2c2f74 to
9121050
Compare
Contributor
valentinewallace
left a comment
There was a problem hiding this comment.
Looks good modulo #4342 needs review (and the PR description needs updating to include it)
|
👋 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. |
2 tasks
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. Backport of 0f253c0
9121050 to
abf5c10
Compare
Collaborator
Author
|
Updated to the merged version of #4342 this should be ready to go. |
|
✅ Added second reviewer: @jkczyz |
valentinewallace
approved these changes
Jan 29, 2026
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 Backport of 5e64c40 Conflicts resolved in: * lightning/src/ln/channelmanager.rs
This is really dumb, `assert!(cfg!(fuzzing))` is a perfectly reasonable thing to write! Backport of 6ff720b
abf5c10 to
45a9d2b
Compare
Collaborator
Author
|
Oops forgot to fix the silent conflicts again. $ git diff-tree -U3 abf5c10716 45a9d2be65
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 3a0f61ccad..02bb67e15c 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -5549,6 +5549,7 @@ where
) -> Result<(), Bolt11PaymentError> {
let best_block_height = self.best_block.read().unwrap().height;
let _persistence_guard = PersistenceNotifierGuard::notify_on_drop(self);
+ let payment_hash = PaymentHash(invoice.payment_hash().to_byte_array());
self.pending_outbound_payments.pay_for_bolt11_invoice(
invoice,
payment_id,
@@ -5563,7 +5564,7 @@ where
best_block_height,
&self.pending_events,
|args| self.send_payment_along_path(args),
- &WithContext::from(&self.logger, None, None, Some(invoice.payment_hash())),
+ &WithContext::from(&self.logger, None, None, Some(payment_hash)),
)
}
@@ -17583,6 +17584,7 @@ where
true,
&mut compl_action,
&pending_events,
+ &logger,
);
// If the completion action was not consumed, then there was no
// payment to claim, and we need to tell the `ChannelMonitor` |
valentinewallace
approved these changes
Jan 29, 2026
jkczyz
approved these changes
Jan 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of #4341, #4259 (which is really a behavior change not a strict bugfix so open to pushback on including it), #4262, #4268, #4274, #4312, #4342