-
Notifications
You must be signed in to change notification settings - Fork 436
[0.2] Backports and cut 0.2.1 #4344
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
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
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 <[email protected]> Backport of cc1eb16
a2c2f74 to
9121050
Compare
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.
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. |
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
|
Updated to the merged version of #4342 this should be ready to go. |
|
✅ Added second reviewer: @jkczyz |
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
|
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` |
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