Conversation
Make pending payment state and dust exposure available to callers so they can inspect stalled payments and assess force-close risk. Also expose the maximum splice-out amount to help plan withdrawals. Expose the same information through Rust and the language bindings. Rust and UniFFI checks, unit tests, the new integration test in both configurations, doctests, and binding generation pass. The full integration run had two failures in existing tests. Both passed in isolation, but channel_full_cycle_force_close_trusted_no_reserve failed again with Bitcoin Core RPC at tests/common/mod.rs:632. Its clean-main run passed, so the cause remains unresolved. UniFFI rustdoc also fails on three broken links reproduced on main. Fixes lightningdevkit#1102 Co-Authored-By: HAL 9000
|
I've assigned @TheBlueMatt as a reviewer! |
f3r10
left a comment
f3r10
left a comment
There was a problem hiding this comment.
Thanks, this looks good to me overall, and the test covering a dust and a non-dust HTLC at the same time is nice.
And about that comment on the commit: I ran channel_full_cycle_force_close_trusted_no_reserve 5× on this branch (4 pass, 1 fail [panic: …]) and 5× on the parent commit (5 pass). That's too few runs to tell whether the test is flaky or something changed here, but since this diff only adds read-only fields to ChannelDetails and nothing in the force-close path touches them, I'd expect a pre-existing flake.
| /// This is compared against [`ChannelConfig::max_dust_htlc_exposure`] when determining whether | ||
| /// new HTLCs can be accepted or offered on this channel. | ||
| /// | ||
| /// Will be `None` for objects serialized with LDK versions prior to 0.3. |
There was a problem hiding this comment.
This line is copied from LDK's docs, but it doesn't apply here: ldk-node only builds ChannelDetails from live channels in list_channels, and LDK always sets Some(..) for those (ChannelDetails::from_channel in channel_state.rs). Maybe drop it, or say it's always Some for channels returned by Node::list_channels? Keeping the Option seems right in case upstream changes. It's just the doc that's misleading.
3 participants
Make pending payment state and dust exposure available to callers so they can inspect stalled payments and assess force-close risk. Also expose the maximum splice-out amount to help plan withdrawals.
Expose the same information through Rust and the language bindings.
Rust and UniFFI checks, unit tests, the new integration test in both configurations, doctests, and binding generation pass. The full integration run had two failures in existing tests. Both passed in isolation, but channel_full_cycle_force_close_trusted_no_reserve failed again with Bitcoin Core RPC at tests/common/mod.rs:632. Its clean-main run passed, so the cause remains unresolved. UniFFI rustdoc also fails on three broken links reproduced on main.
Fixes #1102