-
Notifications
You must be signed in to change notification settings - Fork 760
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
Accept empty header set in range headers validation #4189
Merged
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
b67d557
Accept empty header set in range headers validation
shemnon 68865d7
spotless
shemnon dff648b
changelog
shemnon 0cb74d5
optional changes
shemnon f273e5d
Merge branch 'main' of github.com:hyperledger/besu into erigonShortRe…
shemnon f702945
changelog
shemnon 507839b
spotless
shemnon 1a85782
Merge branch 'main' into erigonShortResponse
macfarla File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
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.
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.
Only question here is if this changes the sync process in any meaningful way - could this cause sync to hang, for example, if we have a peer that is repeatedly returning nothing? It seems that previously we would throw here, and I'm guessing the sync process would be interrupted because of the exception.
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.
@ajsutton - thoughts?
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.
Throwing the exception did not disconnect the peer, so we still had the peer.
But per spec (a) an empty response was 100% fine and (b) Erigon's response was not empty, we just trimmed off the one value we already had. So there are two routes we may be passing in an empty resposne down the pipeline and both cases the peer is behaving validly, so disconnecting doesn't seem right.
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.
Not saying we should disconnect, just want to make sure we're not introducing anything that could cause the sync to stall / get stuck. But we handle useless responses elsewhere, so even if we got stuck asking for the same range of headers from a single unresponsive peer, I think we would eventually disconnect and move on ...
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.
I haven't seen any pauses. Rather than breaking the pipe an empty stream is the result, and that would get aggregated the same as a broken step, as nothing gets added to the next set of object for the next step in the pipeline. I haven't seen any slowdown overnight and I started a fresh sync and it's proceeding the same as before with no observable differences.
Side note: I'm really looking forward to being able to bit-torrent the blocks prior to the merge. EIP-4444 and friends will be welcomed with open arms.