-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
discovery: properly set FirstBlockHeight and NumBlocks in responses #3785
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wpaulino
reviewed
Dec 3, 2019
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.
Changes LGTM, haven't tested in the wild yet.
Linter is failing with:
discovery/syncer_test.go:722: File is not `gofmt`-ed with `-s` (gofmt)
lnwire.ShortChannelID{
cfromknecht
reviewed
Dec 3, 2019
bhandras
requested changes
Dec 5, 2019
cfromknecht
approved these changes
Dec 7, 2019
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.
LGTM 🍣
@Roasbeef needs squash! |
In this commit we fix in a bug in `lnd` that could cause other implementations which implement a strict version of the spec to disconnect when trying to sync their channel graph using the gossip query feature. Before this commit, we would embed the request to a `QueryChannelRange` in the response, causing some clients to reject the response as the `FirstBlockHeight` and `NumBlocks` field would be identical for each chunk of the response. In order to remedy this, we now properly set these two fields with each returned chunk. Note that even after this commit, we keep our existing behavior surrounding the `Complete` field as is. Otherwise, current `lnd` clients which rely on this field (rather than the two aforementioned fields) wouldn't be able to properly detect when a set of responses to their query was "complete". Partially fixes lightningnetwork#3728.
Roasbeef
force-pushed
the
gossip-queries-fix
branch
from
December 11, 2019 01:07
fae17f7
to
6a9b961
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In this commit we fix in a bug in
lnd
that could cause otherimplementations which implement a strict version of the spec to
disconnect when trying to sync their channel graph using the gossip
query feature. Before this commit, we would embed the request to a
QueryChannelRange
in the response, causing some clients to reject theresponse as the
FirstBlockHeight
andNumBlocks
field would beidentical for each chunk of the response.
In order to remedy this, we now properly set these two fields with each
returned chunk. Note that even after this commit, we keep our existing
behavior surrounding the
Complete
field as is. Otherwise, currentlnd
clients which rely on this field (rather than the twoaforementioned fields) wouldn't be able to properly detect when a set of
responses to their query was "complete".
Partially fixes #3728.