Skip to content
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

Ignore partially-pruned channels during routing #3038

Conversation

TheBlueMatt
Copy link
Collaborator

If we prune one side of a channel's ChannelUpdateInfo that means the node hasn't been online for two weeks (as they haven't generated a new channel_update in that time). In such cases, even if we haven't yet pruned the channel entirely, we should definitely not be treating these channels as candidates for routing.

Fixes #1824

@TheBlueMatt TheBlueMatt added this to the 0.1 milestone May 6, 2024
Copy link
Contributor

@shaavan shaavan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code reasoning and logic sound good!
I think we can benefit from a small test addition to check for this specific logic.

@@ -888,12 +889,14 @@ impl ChannelInfo {
return None;
}
};
direction.map(|dir| (DirectedChannelInfo::new(self, dir, outbound), source))
let dir = direction.expect("We checked that both directions are available at the start");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, one quick question.

Usage of expect here would create an explicit panic in case direction.is_none().
But would explicitly panicking in a pub fn be a good idea?

Should we consider returning a Result<Ok, Err>, instead of panicking within the function?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the text in the expect, we expect this to be unreachable :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah! Right!
Then it makes sense! :)

If we prune one side of a channel's `ChannelUpdateInfo` that means
the node hasn't been online for two weeks (as they haven't
generated a new `channel_update` in that time). In such cases, even
if we haven't yet pruned the channel entirely, we should definitely
not be treating these channels as candidates for routing.

Note that this requires some additional `channel_update`s in the
router tests, but all of the new ones are added as disabled
channels.

Fixes lightningdevkit#1824
@TheBlueMatt TheBlueMatt force-pushed the 2024-05-no-dir-with-on-side-offline branch from 29f8a54 to 4fd8cb8 Compare May 9, 2024 15:28
@codecov-commenter
Copy link

codecov-commenter commented May 9, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.54%. Comparing base (37c431a) to head (4fd8cb8).
Report is 29 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3038      +/-   ##
==========================================
+ Coverage   89.85%   90.54%   +0.69%     
==========================================
  Files         116      116              
  Lines       96237   102306    +6069     
  Branches    96237   102306    +6069     
==========================================
+ Hits        86471    92637    +6166     
- Misses       7206     7214       +8     
+ Partials     2560     2455     -105     

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

Copy link
Contributor

@shaavan shaavan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe using a for loop construct for all the added channel_updates will be a cleaner & maintainable way of introducing the new update_channel.

short_channel_id: 6,
timestamp: 1,
flags,
cltv_expiry_delta: (6 << 4) | 0,
Copy link
Contributor

@shaavan shaavan May 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also a tangential question, but why are we writing cltv_expiry_delta: (x<<4) | 0 in this test when it is the same as writing cltv_expiry_delta: (x<<4)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We also |1 in some places and it just keeps the same formatting.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright! That makes sense!
Thanks for the clarification! :)

Copy link
Contributor

@valentinewallace valentinewallace left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's fine, but note that this change means if the user supplies their own routes that contain partially-pruned channels, we then won't score these channels.

@valentinewallace valentinewallace merged commit a95338a into lightningdevkit:main May 21, 2024
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Refuse to create a DirectedChannelInfo if either directional update is missing
5 participants