-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
fuel-core-sync #889
fuel-core-sync #889
Conversation
freesig
commented
Jan 5, 2023
•
edited
edited
- Closes [Sync] Sync task #881
- Closes [Sync] Import task #882
- Closes [Sync] Create sync service wrapper for sync tasks #880
b121512
to
7b101ae
Compare
7b101ae
to
68ea3cb
Compare
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.
The change looks solid, so many tests=D I didn't review all files, will continue later. I left several questions and suggestion
/// This case should not occur but because we must handle | ||
/// it then the most resilient way is to assume that we | ||
/// should re-process the gap. | ||
fn commit_creates_processing( |
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 didn't get it. Why do we want to return Processing
for the range that is committed before?
I guess if new_height
< existing_height
, we need to return Committed(existing_height)
, because it means that we already processed the new_height..existing_height
range before.
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.
So this is a bit of a hard one. Really by design we can't ever have this happen because the commits are run in order and there's no state that can lead to re-running a commit. However I can't handle this case as an error at the stream level because there's nothing you can do so for the sake of completeness I needed to do something here. If we get a commit that is lower then the current commit then something is wrong and my way of looking at this is we can't trust the higher commit value so it should reprocess the headers in between. But you could make an argument either way.
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.
Read through changes but didn't have too much to say from my end, so defer to others as well. But looks good beyond Green's suggestions
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.
Nice work! I left several comments. You can address them now or later=)
let p2p = p2p.clone(); | ||
let consensus_port = consensus.clone(); | ||
move |result| { | ||
let p2p = p2p.clone(); | ||
let consensus_port = consensus_port.clone(); | ||
async move { |
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.
Hmm, it seems we can create this function one time during the creation of the task and use it here. Instead of creating it on each iteration.
But it will affect your current code, so I guess it is enough for now to create it at the begin of the function.
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.
Is that really a concern though? Very likely this just gets optimized away by the compiler.
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.
Also we can't do that because this takes the closure owned so you would need to clone the closure anyway.
let state = state.clone(); | ||
let executor = executor.clone(); | ||
move |block| { |
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.
The same here, we can create it only one time
max_get_header_requests: 10, | ||
max_get_txns_requests: 10, | ||
} | ||
=> is less_or_equal_than Count{ headers: 10, transactions: 10, consensus_calls: 10, executes: 1, blocks: 21 } |
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.
Hmm, how does comparation work? It will compare each field and only if all fields <=
then true
?
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'm assuming it just uses the existing derivation of Ord
/PartialOrd
for the Count
type
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.
Yeh exactly. It's just checking the tests never exceed those maximum values
} | ||
impl<P, E, C> Import<P, E, C> | ||
where | ||
P: PeerToPeerPort + Send + Sync + 'static, |
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.
[nit] I guess you can make Send + Sync
default bound for all ports like PeerToPeerPort: Send + Sync
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.
There's no reason for these traits to be send and sync it's only in this usecase that it's required.
where | ||
P: ports::PeerToPeerPort + Send + Sync + 'static, | ||
E: ports::BlockImporterPort + Send + Sync + 'static, | ||
C: ports::ConsensusPort + Send + Sync + 'static, |
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.
Hmmm, do we need those constraints here? Maybe we can remove them like:
where | |
P: ports::PeerToPeerPort + Send + Sync + 'static, | |
E: ports::BlockImporterPort + Send + Sync + 'static, | |
C: ports::ConsensusPort + Send + Sync + 'static, | |
where | |
P: ports::PeerToPeerPort, |
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.
And for types down, we can remove all constraints, because we don't need them during creation of tasks=)
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.
@xgreenx we actually do because you can't add extra constraints to the run
on RunnableTask
so we are forced to put them on the type.
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.
You can add constraints on the impl
section itself, we did that for all other services.
|
||
#[derive(Debug, Clone, PartialEq, Eq, PartialOrd, Ord, Hash)] | ||
/// Opaque peer identifier. | ||
pub struct PeerId(Vec<u8>); |
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 make a tech-debt cleanup task for updating the other gossip data types here to use this new PeerId type.