Dedup InboundUpdateAdd::Forwarded data; fix PaymentForwarded fields
#4405
Conversation
|
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4405 +/- ##
==========================================
+ Coverage 86.05% 86.07% +0.02%
==========================================
Files 156 156
Lines 103384 103479 +95
Branches 103384 103479 +95
==========================================
+ Hits 88964 89073 +109
+ Misses 11905 11894 -11
+ Partials 2515 2512 -3
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:
|
Useful when using these macros in lightning-tests/upgrade_downgrade_tests
In the next commit, we want to dedup fields between the InboundUpdateAdd::Forwarded's HTLCPreviousHopData and the outer InboundHTLCOutput/Channel structs, since many fields are duplicated in both places at the moment. As part of doing this cleanly, we first refactor the method that retrieves these InboundUpdateAdds for reconstructing the set of pending HTLCs during ChannelManager deconstruction. Co-Authored-By: Claude Opus 4.5 <[email protected]>
Previously, the InboundUpdateAdd::Forwarded enum variant contained an HTLCPreviousHopData, which had a lot of fields that were redundant with the outer InboundHTLCOutput/Channel structs. Here we dedup those fields, which is important because the pending InboundUpdateAdds are persisted whenever the ChannelManager is persisted.
We need these fields to generate a correct PaymentForwarded event if we need to claim this inbound HTLC backwards after restart and it's already been claimed and removed on the outbound edge.
Previously, we were spuriously using the upstream channel's info when we should've been using the downstream channel's.
Previously, if a forwarding node reloaded mid-HTLC-forward with a preimage in the outbound edge monitor and the outbound edge channel still open, and subsequently reclaimed the inbound HTLC backwards, the PaymetForwarded event would be missing the next_user_channel_id field.
0d38512 to
94cb95d
Compare
Test that if we restart and had two inbound MPP-part HTLCs received over the same channel in the holding cell prior to shutdown, and we lost the holding cell prior to restart, those HTLCs will still be claimed backwards. Test largely written by Claude
|
Still need to finalize what manager version to write (#4303 (comment)), but otherwise this should be good to go. |
InboundUpdateAdd::Forwarded data with outer structsInboundUpdateAdd::Forwarded data; fix PaymentForwarded fields
| } | ||
|
|
||
| #[test] | ||
| fn test_reclaim_after_reload_payment_forwarded_ev() { |
There was a problem hiding this comment.
I need to fix this test, thought it was right at one point but it passes incorrectly. Will fix on the next push.
TheBlueMatt
left a comment
There was a problem hiding this comment.
Didn't review the test changes but otherwise basically lgtm.
| pub(super) fn inbound_forwarded_htlcs( | ||
| &self, | ||
| ) -> impl Iterator< | ||
| Item = (PaymentHash, HTLCPreviousHopData, u64, ChannelId, PublicKey, OutPoint, u128), |
There was a problem hiding this comment.
Heh, this looks like it needs a struct now. Maybe even leave the payment_hash out of it so that we can reuse it as the map value in channelmanager.rs.
Previously, the
InboundUpdateAdd::Forwardedenum variant contained anHTLCPreviousHopData, which had a lot of fields that were redundant with theouter
InboundHTLCOutput/Channelstructs. Here we dedup those fields, which isimportant because the pending
InboundUpdateAddsare persisted whenever theChannelManageris persisted.Based on #4303Partially addresses #4286