-
Notifications
You must be signed in to change notification settings - Fork 332
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
WIP Connection queries for Relayer #136
Conversation
…files generated but replacing connection mod breaks the build
Ready for review! ! Before merging: Because of the code which
We have two options:
Later edit:The |
@@ -42,6 +42,15 @@ impl State { | |||
Self::Open => "OPEN", | |||
} | |||
} | |||
|
|||
pub fn from_i32(nr: i32) -> Self { |
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.
@ancazamfir was not sure this is accurate, please double-check.
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.
Looks good.
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 hate to be "that guy" but cherry-picking the proto files for each use-case will become a hassle very quickly. I tried importing them all to see the interconnectedness and in my experience, it's worth keeping proto definitions together.
See the ibc-proto crate for the results or https://github.com/informalsystems/ibc-proto for the source code.
I suggest we use that crate or at least import its findings for a more complete proto experience.
match pc.counterparty { | ||
Some(cp) => { | ||
let mut conn = ConnectionEnd::new( | ||
ClientId::from_str(&pc.client_id).unwrap(), |
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.
Could we get rid of the unwrap()
s? If the user issues a query command and gets back a few pages of traces it does not help. I had this comment earlier but I guess it got lost. Try to query with non-exsiting connection id.
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'd like to make this into a From trait, if possible.
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 I guess this should be verifying all the fields, not just 2? And should we really have an error per field or maybe start with a more general InvalidConnectionEnd error of some kind and include what's missing as a string? Not sure ...
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'd like to make this into a From trait, if possible.
Either option could work, the question is if we want to keep validation inside the from
or outside. The current code uses the FromStr
trait, with the signature fn from_str(s: &str) -> Result<Self, Self::Err>
so we can do validation inside there and return error if validation fails. With From
, the sig is fn from(T) -> Self
so we'd have to do validation after calling from
. Is it generally speaking, or specifically in this case, better to do validation outside of from
?
LE: Maybe this helps?
Also I guess this should be verifying all the fields, not just 2?
Agree this deserves a discussion to find a more principled approach.
@@ -32,6 +32,10 @@ impl CommitmentProof { | |||
*/ | |||
|
|||
#[derive(Clone, Debug, PartialEq, Serialize, Deserialize)] | |||
pub struct CommitmentPrefix; | |||
pub struct CommitmentPrefix(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.
Wondering if we should have a formatter for this. The output of the query shows: prefix: CommitmentPrefix([112, 114, 101, 102, 105, 120]) }
(decimal), in the genesis and curl it's cHJlZml4
(base64), ascii is "prefix"
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.
Implemented a fmt::Debug trait to properly format the CommitmentPrefix output in this commit
Module |
Why would you need |
* Initial implementation of proto files required for connection. Proto files generated but replacing connection mod breaks the build * Removed reference to MerklePrefix * Implemented logic to proto_unmarshall the connection using prost informalsystems#130 * Trimmed the proto file, fixed commitments. Ready for review. (informalsystems#130) * Fixed a couple of nits * Fix for unused_qualifications h/t @gregszabo @andynog. * Fixing unit testing since CommitPrefix was changed, failed to cargo build informalsystems#136 * Replaced prost compilation with dependency on ibc-proto crate. * Better error propagation in connection query. * Fixed error handling when specifying height (-h) parameter in a query connection. Doesn't throw exception anymore. Show error message. informalsystems#130 * Added validation for versions in ConnectionEnd unmarshalling * Implemented fmt::Debug trait for CommitPrefix to properly display its value (string instead of vector of bytes). Assumes value is valid utf-8. informalsystems#136 Co-authored-by: Andy Nogueira <me@andynogueira.dev>
Closes: #130
Description
For contributor use:
docs/
) and code commentsFiles changed
in the Github PR explorer