Misc Followups

[TheBlueMatt]

Mostly post-#3801 things, not entirely.

[ldk-reviews-bot]

👋 Thanks for assigning @joostjager as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[joostjager]

The unrounded hold times should be strictly greater, but clearly after rounding that may not be the case anymore. Not sure if that's fully clear now.

[TheBlueMatt]

I don't think that's true? As long as everyone rounds in the same way (truncating, rather than rounding) a >= condition will hold after rounding.

[joostjager]

I thought strictly greater means > not >=

[TheBlueMatt]

Oh lol, yea, I see why its confusing. Pushed a fixup:

$ git diff-tree -U2 517610c2c 15a70f1d9
diff --git a/lightning/src/events/mod.rs b/lightning/src/events/mod.rs
index 1a6a18d928..e4fd7ad2ef 100644
--- a/lightning/src/events/mod.rs
+++ b/lightning/src/events/mod.rs
@@ -1105,11 +1105,12 @@ pub enum Event {
 		/// The time that each hop indicated it held the HTLC.
 		///
-		/// We expect that at each hop the hold time will be strictly greater than the hold time of
-		/// the following hops, as a node along the path shouldn't have completed the HTLC until
-		/// the next node has completed it.
-		///
 		/// The unit in which the hold times are expressed are 100's of milliseconds. So a hop
 		/// reporting 2 is a hold time that corresponds to between 200 and 299 milliseconds.
 		///
+		/// We expect that at each hop the actual hold time will be strictly greater than the hold
+		/// time of the following hops, as a node along the path shouldn't have completed the HTLC
+		/// until the next node has completed it. Note that because hold times are in 100's of ms,
+		/// hold times as reported are likely to often be equal across hops.
+		///
 		/// If our peer didn't provide attribution data or the HTLC resolved on chain, the list
 		/// will be empty.
@@ -1172,11 +1173,12 @@ pub enum Event {
 		/// The time that each hop indicated it held the HTLC.
 		///
-		/// We expect that at each hop the hold time will be strictly greater than the hold time of
-		/// the following hops, as a node along the path shouldn't have completed the HTLC until
-		/// the next node has completed it.
-		///
 		/// The unit in which the hold times are expressed are 100's of milliseconds. So a hop
 		/// reporting 2 is a hold time that corresponds to between 200 and 299 milliseconds.
 		///
+		/// We expect that at each hop the actual hold time will be strictly greater than the hold
+		/// time of the following hops, as a node along the path shouldn't have completed the HTLC
+		/// until the next node has completed it. Note that because hold times are in 100's of ms,
+		/// hold times as reported are likely to often be equal across hops.
+		///
 		/// If our peer didn't provide attribution data or the HTLC resolved on chain, the list
 		/// will be empty.

[ldk-reviews-bot]

👋 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.

[TheBlueMatt]

Fixed a bug in the bench build:

$ git diff-tree -U3 865519c6b 517610c2c
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index e9052209d4..76c972fe8a 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -18317,7 +18317,7 @@ pub mod bench {
 				expect_payment_claimed!(ANodeHolder { node: &$node_b }, payment_hash, 10_000);

 				match $node_b.get_and_clear_pending_msg_events().pop().unwrap() {
-					MessageSendEvent::UpdateHTLCs { node_id, channel_id: _, updates } => {
+					MessageSendEvent::UpdateHTLCs { node_id, mut updates, .. } => {
 						assert_eq!(node_id, $node_a.get_our_node_id());
 						let fulfill = updates.update_fulfill_htlcs.remove(0);
 						$node_a.handle_update_fulfill_htlc($node_b.get_our_node_id(), fulfill);

[codecov]

Codecov Report

Attention: Patch coverage is 96.86099% with 7 lines in your changes missing coverage. Please review.

Project coverage is 89.05%. Comparing base (2f9898c) to head (517610c).

Files with missing lines	Patch %	Lines
lightning/src/ln/chanmon_update_fail_tests.rs	96.20%	1 Missing and 2 partials ⚠️
lightning/src/util/test_utils.rs	0.00%	2 Missing ⚠️
lightning-net-tokio/src/lib.rs	0.00%	1 Missing ⚠️
lightning/src/ln/peer_handler.rs	50.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3942   +/-   ##
=======================================
  Coverage   89.05%   89.05%           
=======================================
  Files         167      167           
  Lines      121800   121812   +12     
  Branches   121800   121812   +12     
=======================================
+ Hits       108464   108482   +18     
+ Misses      10928    10927    -1     
+ Partials     2408     2403    -5     

Flag	Coverage Δ
fuzz	22.72% <61.11%> (-0.37%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.