[0.2] Backports and cut 0.2.1 #4344
Open
Conversation
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
|
I've assigned @valentinewallace as a reviewer! |
TheBlueMatt
force-pushed
the
2026-0.2-0.2.1
branch
2 times, most recently
from
f455df3 to
9ad9bf4
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## 0.2 #4344 +/- ##
==========================================
- Coverage 88.87% 86.05% -2.83%
==========================================
Files 180 156 -24
Lines 138117 99894 -38223
Branches 138117 99894 -38223
==========================================
- Hits 122752 85961 -36791
+ Misses 12543 11434 -1109
+ Partials 2822 2499 -323
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:
|
TheBlueMatt
force-pushed
the
2026-0.2-0.2.1
branch
3 times, most recently
from
4bced05 to
1ce59e5
Compare
TheBlueMatt
force-pushed
the
2026-0.2-0.2.1
branch
from
1ce59e5 to
b035089
Compare
TheBlueMatt
changed the title
This was referenced Jan 26, 2026
TheBlueMatt
force-pushed
the
2026-0.2-0.2.1
branch
from
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
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 simplify some of the changes that will be required to remove `OutboundPayments::logger` and pass it in from calsites (with context required) by adding a proc-macro that will at least add the required bounds and parameters to `outbound_payments.rs` and pass the logger automatically when we call methods on `self`. Backport of 9347053
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 7005581
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 lightningdevkit#4307 Backport of b949af6 Several straightforward 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
TheBlueMatt
force-pushed
the
2026-0.2-0.2.1
branch
2 times, most recently
from
d4944bf to
a2c2f74
Compare
TheBlueMatt
force-pushed
the
2026-0.2-0.2.1
branch
from
a2c2f74 to
9121050
Compare
Contributor
valentinewallace
left a comment
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 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