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

Added single-step-skipping JSON tests #143

Merged
merged 6 commits into from
Feb 6, 2020

Conversation

Shivani912
Copy link
Contributor

Purpose: To add the remaining single step skipping JSON test cases

Changes:

  • Modified the test case structure -> test_name is changed to batch_name
  • Diretory structure -> Categorized and split the json files into single_step_sequential and single_step_skipping
  • Added tests for single_step_skipping cases

@liamsi
Copy link
Member

liamsi commented Feb 3, 2020

@Shivani912 Can you point me to the exact case in the JSON where the tests pass despite the wrong header hash?

"expected_output": "error"
},
{
"description": "Case: one lite block, wrong PartsHeader.Total, with error",
Copy link
Member

Choose a reason for hiding this comment

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

That's the problematic test!

@liamsi
Copy link
Member

liamsi commented Feb 3, 2020

0a30022 solves the problem with the "Case: one lite block, wrong PartsHeader.Total, with error", next one in that file is "Case: one lite block, less than one-third vals don't sign, no error"

"type": "tendermint/PubKeyEd25519",
"value": "b6hwk3pjiOTJfLVCcLDA3I3lO71zWJ0VSded5LUl9T0="
},
"voting_power": "50",
Copy link
Member

@liamsi liamsi Feb 4, 2020

Choose a reason for hiding this comment

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

That's the next test that is failing. Quick question: Should we rename this to: "Case: one lite block, more than two-third vals did sign, no error". I was first confused why there is no error if less than 1/3 signed :-D The

This one seems to fail on the newly introduced check in regarding the parts.hash btw:

i: 0, Case: one lite block, less than one-third vals don't sign, no error
parts.hash: Hash::Sha256(F7338645FBBEE68EC2F2A9F4AE6DB46DDC720A75760E08A5323FE8BF2CBEFBE2)
self.header_hash(): Hash::Sha256(EEE5DE7802C5519394F4A4986AAB9B9D9E1F2C736289182104E8C342559753EF)

I don't fully understand why this doesn't err on the go side too: https://github.com/tendermint/tendermint/blob/df3eee455c9d2a4a9698a35aa0dfe6d5d2efd53d/types/block.go#L778-L784

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh it's "less than one-third don't sign" which is same as "more than two-thirds did sign". That's why it does not error on the go side too.

Copy link
Member

Choose a reason for hiding this comment

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

Me wondering was more about the parts hash. I understand the equiv. of both and suggested to rename the description to the latter "more than two-thirds did sign" as it is less confusing (but maybe it's just me).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah okay. I can do that

@@ -47,6 +47,12 @@ impl lite::Commit for block::signed_header::SignedHeader {
if self.commit.precommits.len() != vals.validators().len() {
return Err(lite::Error::InvalidCommitSignatures);
}
if let Some(parts) = &self.commit.block_id.parts {
if parts.hash != self.header_hash() {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@liamsi parts.hash is the merkleRoot(partsHeader) which is different from the header_hash. That's why this check is making many other tests to fail too. We want to check that the commit.BlockID is equal to each of the precommit.BlockID. In reality, there can be precommits for other blocks and that's totally fine. But then, those precommits should not be considered for this block. This means that when we calculate the total voting power i.e. signed_power, we do not count voting power of validators who signed these precommits. Maybe this check should go under the voting_power_in method(?)

Copy link
Member

Choose a reason for hiding this comment

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

I see. Thanks for the clarification! To move forward, I'd suggest to merge this, and open an issue referencing this comment and the failing test.

Copy link
Member

Choose a reason for hiding this comment

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

Oh, is this about the bug I raised here: #145 (comment) ? We should be testing (either here or in voting_power_in) that the votes being tallied are for the right block ID

@codecov-io
Copy link

Codecov Report

Merging #143 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #143   +/-   ##
=======================================
  Coverage   36.08%   36.08%           
=======================================
  Files          90       90           
  Lines        3140     3140           
  Branches      490      490           
=======================================
  Hits         1133     1133           
+ Misses       1751     1750    -1     
- Partials      256      257    +1
Impacted Files Coverage Δ
tendermint/src/lite_impl/signed_header.rs 84.44% <ø> (+2.22%) ⬆️
tendermint/src/merkle.rs 75.67% <0%> (-1.36%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0ca3e8c...413b780. Read the comment docs.

@liamsi liamsi marked this pull request as ready for review February 5, 2020 18:49
Copy link
Member

@liamsi liamsi left a comment

Choose a reason for hiding this comment

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

It seems now that some of the existing test files can be deleted? Even the descriptions are the same. I think it's fine to review and remove those unless they contain further test cases which aren't in the new ones. The rest LGTM! 💪

@Shivani912
Copy link
Contributor Author

It seems now that some of the existing test files can be deleted? Even the descriptions are the same. I think it's fine to review and remove those unless they contain further test cases which aren't in the new ones. The rest LGTM! 💪

Done!

Copy link
Member

@liamsi liamsi left a comment

Choose a reason for hiding this comment

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

Awesome! Thanks @Shivani912!

One last ask: Can you link to the version of your go-code with which you've generated the JSON files? E.g. just here in the comments; could be via linking a commit (after that do not force push in your branch please). Then someone could reproduce this :-)

@liamsi liamsi merged commit 994b457 into informalsystems:master Feb 6, 2020
@liamsi
Copy link
Member

liamsi commented Feb 6, 2020

Congrats to your 1st contribution to tendermint-rs 🎉 👍

@Shivani912
Copy link
Contributor Author

Awesome! Thanks @Shivani912!

One last ask: Can you link to the version of your go-code with which you've generated the JSON files? E.g. just here in the comments; could be via linking a commit (after that do not force push in your branch please). Then someone could reproduce this :-)

Here: https://github.com/Shivani912/tendermint/tree/shivani-refactor/types/lite-client
I'll be pushing some more code soon!

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.

None yet

4 participants