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.
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 a way to fetch transactions in P2P without specifying a peer #2376
Add a way to fetch transactions in P2P without specifying a peer #2376
Changes from 3 commits
42719bf
c80f3ac
130cb86
851f9d8
be68c8a
024c33f
60db84f
4be029e
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 think we can remove this variant
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 think it's useful in case of syncing when you already received the header from someone in the current syncing process and so you can directly ask him without having to redo peer selection. Maybe there is also othhers use cases but this is the only one I see.
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.
It seems that after your PR we don't need this variant anymore. But we can address it in your PR
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.
Mhhh yeah let's discuss it in the other PR because IMO what I have written above still works in certain cases.
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.
We should return error to the
channel
ifpeer
isNone
, to allow proper handling of it by the caller.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 can change it, ok. However, I want to ask if we want the same in
GetSealedHeaders
(just above in the code) ? It has the same behavior and doesn't return the error for now.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.
Yep, good catch, let's fix it as well
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.
Done. It complexify a bit the type in the channel because we have a two-stage error type but with unification of return type etc that we want to do in p2p maybe we could improve this in the future.
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.
perhaps we should continue to use the
TaskRequest::GetTransactionsFromPeer
and perform peer selection for a given block height instead -fuel-core/crates/services/p2p/src/service.rs
Lines 264 to 266 in f597ac9
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 personally think that there is still use case where it's interesting to already give a peer that we know have the information, we use this un sync service.
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.
right, i agree ~ but this information is also valid for a peer returned by
get_peer_id_with_height
. perhaps we should not duplicate valid peers for a given height then.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 don't get your comment. My flow is that I ask for an header and so the peer is returned along with the header then I can directly ask to this peer about the transactions because in our network if you have the header we assume you have the transactions. It avoid running this
get_peer_id_with_height
function that can be costly.Maybe I miss your point and in this case we can go over more voice discussion :)
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.
If we do peer selection outside of the
run
loop, we can face race condition were peer is disconnected already