-
Notifications
You must be signed in to change notification settings - Fork 329
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
Perform bisection when verifying headers using the light client #51
Conversation
I tried to run the relayer on this branch and I don't see the light client update header messages. Just these: If I remove the relay thread then the relayer finishes quietly after
Maybe I am doing smthg wrong, it's the first time I try this; followed the instructions from: https://github.com/informalsystems/ibc-rs/blob/master/README.md |
Yeah, I get the same output too. My bad, I should have mentioned that and marked the PR as a draft. Will let you know once(if) it works and is actually ready for review. |
a5ef581
to
05dc0d9
Compare
ah ok, thought is ready for review :) |
I had forgotten to This now works as expected but has not been rebased on master yet. I rebased locally, but the |
Blocked by informalsystems/tendermint-rs#196 (comment). |
Unblocked now that informalsystems/tendermint-rs#210 has been merged. |
05dc0d9
to
a6a5473
Compare
@ancazamfir Ready for review. |
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.
Thanks! This looks good to me, a couple minor comments. There's a bit more cleanup imo that needs to be done, but we can do in a separate PR.
interval.tick().await; | ||
} | ||
} | ||
|
||
async fn update_headers<C: Chain, S: Store<C>>(mut client: Client<C, S>) { | ||
async fn update_client<C: Chain, S: Store<C>>(mut client: Client<C, S>) { | ||
debug!(chain.id = %client.chain().id(), "updating headers"); | ||
|
||
let mut interval = tokio::time::interval(Duration::from_secs(3)); |
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.
From the documentation: "Note that when it starts, it produces item too." So the interval.tick().await;
should be the first in the loop. I looked at the logs when running with two chains and noticed two updates per chain without the wait when starting the relayer.
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.
Good catch!
debug!(chain.id = %client.chain().id(), "updating headers"); | ||
|
||
let mut interval = tokio::time::interval(Duration::from_secs(3)); | ||
|
||
loop { | ||
info!(chain.id = %client.chain().id(), "updating client"); |
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.
info!(chain.id = %client.chain().id(), "updating client"); | |
interval.tick().await; | |
info!(chain.id = %client.chain().id(), "updating client"); |
and remove from end of loop.
debug!(chain.id = %client.chain().id(), "updating headers"); | ||
|
||
let mut interval = tokio::time::interval(Duration::from_secs(3)); | ||
|
||
loop { | ||
info!(chain.id = %client.chain().id(), "updating client"); | ||
|
||
let result = client.update(SystemTime::now()).await; |
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 believe this is the only place we should upate client, i.e. remove from client.rs
--- a/relayer/relay/src/client.rs
+++ b/relayer/relay/src/client.rs
@@ -93,10 +93,6 @@ where
client.init_with_trust_options(trust_options).await?;
}
- // Perform an update already, to make sure the client is up-to-date.
- // TODO: Should we leave this up to the responsibility of the caller?
- let _ = client.update(SystemTime::now()).await?;
-
Ok(client)
}```
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 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.
After restarting the relayer that had previously sync-ed some header, there are some debug messages about hashes not matching and trusted options height < header height in store. I think we need to look into this a bit, not sure why they occur as this is seen with good providers/ chains. Raised #53 for this.
Just addressed your comments :) |
Looks good! Thanks @romac! |
…rmalsystems#51) * Perform bisection when verifying new headers in client * Fix typo in README * Tick interval at the beginning of the client loop * Do not update the light client upon creation * Improve client logs
Closes: #49
Description
This PR implements proposal B described in #49.
All tasks spawned in the
start
command are now spawned on a local task set which executes them all on the same thread, ie. the main thread.This seems like an acceptable solution to me given that the overall architecture of the relayer and the light client will likely change quite a bit in the coming weeks.
For contributor use:
docs/
) and code commentsFiles changed
in the Github PR explorer