Skip to content

routing: ignore ChannelUpdates for unknown channels#2549

Merged
halseth merged 3 commits intolightningnetwork:masterfrom
halseth:router-ignore-unknown-chanupdate
Feb 14, 2019
Merged

routing: ignore ChannelUpdates for unknown channels#2549
halseth merged 3 commits intolightningnetwork:masterfrom
halseth:router-ignore-unknown-chanupdate

Conversation

@halseth
Copy link
Contributor

@halseth halseth commented Jan 28, 2019

Since we should always get a ChanInfo before a channel update, we can exit early if we receive a ChannelUpdate for an edge not in the graph.

Earlier we would attempt to GetUTXO in the case we couldn't find it in the graph, which is a heavy operation for some backends, with the subsequent UpdateEdgePolicy failing regardless.

Broken off of #2279

@halseth halseth force-pushed the router-ignore-unknown-chanupdate branch from d4eb3e8 to 883314b Compare January 28, 2019 08:18
@Roasbeef Roasbeef added this to the 0.6 milestone Jan 28, 2019
@Roasbeef Roasbeef added discovery Peer and route discovery / whisper protocol related issues/PRs bug fix gossip P2 should be fixed if one has time labels Feb 1, 2019
@Roasbeef Roasbeef requested a review from wpaulino February 1, 2019 01:28
wpaulino
wpaulino previously approved these changes Feb 1, 2019
Copy link
Contributor

@wpaulino wpaulino left a comment

Choose a reason for hiding this comment

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

LGTM 🐲

t.Parallel()

const startingBlockHeight = 101
ctx, cleanUp, err := createTestCtxFromFile(startingBlockHeight,
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: function args should be formatted on their own line.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed: 29bd228


// Add the edge between the two unknown nodes to the graph, and check
// that the nodes are found after the fact.
fundingTx, _, chanID, err := createChannelEdge(ctx,
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed: 29bd228

@halseth halseth force-pushed the router-ignore-unknown-chanupdate branch 2 times, most recently from 448945b to 29bd228 Compare February 4, 2019 12:00
@halseth
Copy link
Contributor Author

halseth commented Feb 4, 2019

PTAL @wpaulino

@halseth halseth force-pushed the router-ignore-unknown-chanupdate branch from 29bd228 to e5ac668 Compare February 4, 2019 12:01
@halseth halseth requested a review from joostjager February 5, 2019 09:49
Copy link
Contributor

Choose a reason for hiding this comment

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

We return a slightly different error object than before. Is it okay with the callers?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good question! I looked into this, and the error will eventually be delivered back to the gossiper.

Previously we would log the error and start rejecting this channel:

d.recentRejects[msg.ShortChannelID.ToUint64()] = struct{}{}

While we now will just ignore it, and process it as normal if we later receive it.

Note however, that this is situation most likely will never occur, since the gossiper does its own existence check first:

chanInfo, _, _, err := d.cfg.Router.GetChannelByID(msg.ShortChannelID)

Copy link
Contributor

Choose a reason for hiding this comment

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

Can the situation occur if something happens in between the two db queries for the channel?

Copy link
Contributor

Choose a reason for hiding this comment

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

Even if it does, the error is handled correctly by the caller here:

if err := d.cfg.Router.UpdateEdge(update); err != nil {

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, clear.

The other use of UpdateEdge is in ChannelRouter.applyChannelUpdate. But I think the behaviour improves there too?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes looks okay:

if err != nil && !IsError(err, ErrIgnored, ErrOutdated) {

@halseth halseth force-pushed the router-ignore-unknown-chanupdate branch from e5ac668 to 69ad94c Compare February 7, 2019 14:23
@halseth
Copy link
Contributor Author

halseth commented Feb 12, 2019

PTAL @joostjager @wpaulino

@halseth halseth force-pushed the router-ignore-unknown-chanupdate branch from 69ad94c to 01ea797 Compare February 14, 2019 13:21
@halseth halseth merged commit acd458d into lightningnetwork:master Feb 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug fix discovery Peer and route discovery / whisper protocol related issues/PRs gossip P2 should be fixed if one has time

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants