-
Notifications
You must be signed in to change notification settings - Fork 366
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
Add node id to remaining RoutingMessageHandler::handle_
methods
#3291
Add node id to remaining RoutingMessageHandler::handle_
methods
#3291
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3291 +/- ##
==========================================
- Coverage 89.64% 89.60% -0.04%
==========================================
Files 126 126
Lines 102185 102208 +23
Branches 102185 102208 +23
==========================================
- Hits 91599 91586 -13
- Misses 7863 7892 +29
- Partials 2723 2730 +7 ☔ View full report in Codecov by Sentry. |
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.
Thanks. Boy that Option
really exposes how awkward it is that we loop messages back around to the gossip handler doesn't it...
Anyway, there's some tests that are passing messages to a node with the source being Some(its own pubkey)
, which seems weird, but I'm not sure it matters that much. We could just as well pas None
for all of them.
Yeah, agree that it's not super pretty. Let me know if you have a better approach in mind,
Yeah, while we currently could give |
I do not have any better ideas.
Nah, it all seems fine, not worth adding a ton of code to calculate the "right" pubkey everywhere. |
bc69711
to
d7c4582
Compare
Now added the discussed refactor to take Also rebased to resolve minor conflicts with main. |
CI is sad. Happy to ACK otherwise. |
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.
Just gonna land this cause rebasing it will be a nightmare.
Ah, yea, doesnt pass CI... |
Previously, some `RoutingMessageHandler::handle_` methods (in particular the ones handling node and channel announcements, as well as channel updates, omitted the `their_node_id` argument. This didn't allow implementors to discern *who* sent a particular method. Here, we add `their_node_id: Option<&PublicKey>` to have them learn who sent a message, and set `None` if our own node it the originator of a broadcast operation.
d7c4582
to
3eaa13e
Compare
Force-pushed with minor changes addressing the silent rebase conflicts: > git diff-tree -U2 d7c458236 3eaa13e17
diff --git a/lightning/src/routing/gossip.rs b/lightning/src/routing/gossip.rs
index 92b31311c..4bcb8b859 100644
--- a/lightning/src/routing/gossip.rs
+++ b/lightning/src/routing/gossip.rs
@@ -2599,5 +2599,5 @@ pub(crate) mod tests {
};
- match gossip_sync.handle_node_announcement(&valid_announcement) {
+ match gossip_sync.handle_node_announcement(Some(node_1_pubkey), &valid_announcement) {
Ok(res) => assert!(res),
Err(_) => panic!()
@@ -2739,5 +2739,5 @@ pub(crate) mod tests {
// Don't relay valid channels with excess data
- match gossip_sync.handle_channel_announcement(&valid_excess_data_announcement) {
+ match gossip_sync.handle_channel_announcement(Some(node_1_pubkey), &valid_excess_data_announcement) {
Ok(res) => assert!(!res),
_ => panic!()
@@ -3883,5 +3883,4 @@ pub(crate) mod tests {
gossip_sync.handle_node_announcement(Some(node_1_pubkey), &announcement).unwrap();
assert!(!network_graph.read_only().node(&node_1_id).unwrap().is_tor_only());
- assert!(!network_graph.read_only().node(&node_1_id).unwrap().is_tor_only());
let announcement = get_signed_node_announcement( |
I think the linting CI fail is preexisting? |
In order to maintain interface consistency, we refactor all message handler interfaces to take `PublicKey` rather than `&PublicKey`, as the difference in efficiency should be negigible and the former is easier to handle in binding languages. Over time, we also want to move (no pun intended) towards all messaging interfaces using move semantics, so dropping the reference for `PublicKey` is the first step in this direction.
3eaa13e
to
b172942
Compare
Force pushed again, previously forgot to refactor |
…node-id-routing-msg-handler Add node id to remaining `RoutingMessageHandler::handle_` methods
Previously, some
RoutingMessageHandler::handle_
methods (in particular the ones handling node and channel announcements, as well as channel updates, omitted thetheir_node_id
argument. This didn't allow implementors to discern who sent a particular method.Here, we add
their_node_id: Option<&PublicKey>
to have them learn who sent a message, and setNone
if our own node it the originator of a broadcast operation.