Skip to content
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

Merged
merged 12 commits into from
Jul 14, 2020
Merged

WIP Connection queries for Relayer #136

merged 12 commits into from
Jul 14, 2020

Conversation

adizere
Copy link
Member

@adizere adizere commented Jul 9, 2020

Closes: #130

Description


For contributor use:

  • Unit tests written
  • Added test to CI if applicable
  • Updated CHANGELOG_PENDING.md
  • Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • Updated relevant documentation (docs/) and code comments
  • Re-reviewed Files changed in the Github PR explorer

@adizere adizere marked this pull request as ready for review July 10, 2020 13:01
@adizere adizere requested a review from romac as a code owner July 10, 2020 13:01
@adizere
Copy link
Member Author

adizere commented Jul 10, 2020

Ready for review!

! Before merging:

Because of the code which prost generates (based on the .proto file), we had to disable unused_qualifications warnings here.
The explicit warning originates from the .rs file generated by prost:

  Compiling relayer-modules v0.0.1 (/Users/adi/Hammers/ibc-rs/modules)
error: unnecessary qualification
  --> /Users/adi/Hammers/ibc-rs/target/debug/build/relayer-modules-4a039a021af40008/out/connection.rs:12:13
   |
12 |     pub id: std::string::String,
   |             ^^^^^^^^^^^^^^^^^^^
   |
note: the lint level is defined here
  --> modules/src/lib.rs:9:5
   |
9  |     unused_qualifications,
   |     ^^^^^^^^^^^^^^^^^^^^^

We have two options:

  1. keep the warnings disabled, or
  2. re-enable the warnings and bypass the prost compilation step, i.e., we put in our codebase not the .proto files but the final .rs files, modified by hand to pass the unused_qualifications warning.

Later edit:

The unnecessary qualification issue should be fixed in commit 107cccb

@@ -42,6 +42,15 @@ impl State {
Self::Open => "OPEN",
}
}

pub fn from_i32(nr: i32) -> Self {
Copy link
Member Author

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

Copy link
Member

@greg-szabo greg-szabo left a 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(),
Copy link
Collaborator

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.

Copy link
Member

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.

Copy link
Member

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 ...

Copy link
Member Author

@adizere adizere Jul 14, 2020

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>);
Copy link
Collaborator

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"

Copy link
Contributor

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

@adizere adizere self-assigned this Jul 13, 2020
@adizere
Copy link
Member Author

adizere commented Jul 13, 2020

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.

Module ibc_proto::ibc is private [E0603] :( can we have a quick fix for this @greg-szabo ?

@greg-szabo
Copy link
Member

Why would you need ibc_proto::ibc? It's redundant.
use ibc_proto::connection or similar works. Check the documentation: https://docs.rs/ibc-proto/0.1.0/ibc_proto/

@greg-szabo greg-szabo merged commit fa4cf48 into master Jul 14, 2020
@greg-szabo greg-szabo deleted the andy/proto branch July 14, 2020 23:05
hu55a1n1 pushed a commit to hu55a1n1/hermes that referenced this pull request Sep 13, 2022
* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

query connection given connection_id
5 participants