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

Light Client: Follow-up #284

Merged
merged 21 commits into from
Jun 9, 2020
Merged

Light Client: Follow-up #284

merged 21 commits into from
Jun 9, 2020

Conversation

romac
Copy link
Member

@romac romac commented May 27, 2020

See #280

  • Referenced an issue explaining the need for the change
  • Updated all relevant documentation in docs
  • Updated all code comments where relevant
  • Wrote tests
  • Updated CHANGES.md

@romac romac marked this pull request as draft May 27, 2020 16:04
@codecov-commenter
Copy link

codecov-commenter commented May 27, 2020

Codecov Report

Merging #284 into master will decrease coverage by 0.5%.
The diff coverage is 52.1%.

Impacted file tree graph

@@           Coverage Diff            @@
##           master    #284     +/-   ##
========================================
- Coverage    31.0%   30.5%   -0.6%     
========================================
  Files         129     127      -2     
  Lines        4905    4580    -325     
  Branches     1549    1416    -133     
========================================
- Hits         1525    1398    -127     
+ Misses       2294    2215     -79     
+ Partials     1086     967    -119     
Impacted Files Coverage Δ
light-client/src/components/fork_detector.rs 19.0% <0.0%> (-2.1%) ⬇️
light-client/src/components/io.rs 2.2% <0.0%> (-0.2%) ⬇️
light-client/src/contracts.rs 63.6% <0.0%> (-36.4%) ⬇️
light-client/src/errors.rs 0.0% <ø> (ø)
light-client/src/light_client.rs 42.8% <0.0%> (+0.8%) ⬆️
light-client/src/macros.rs 23.0% <ø> (ø)
light-client/src/predicates/errors.rs 16.6% <0.0%> (-1.0%) ⬇️
light-client/src/state.rs 26.3% <ø> (ø)
light-client/src/store.rs 0.0% <ø> (ø)
light-client/src/store/sled.rs 0.0% <0.0%> (ø)
... and 67 more

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 cf0763e...4590350. Read the comment docs.

@romac romac mentioned this pull request May 27, 2020
19 tasks
@brapse
Copy link
Contributor

brapse commented Jun 2, 2020

Amazing documentation with traceability to the english spec 😍

@romac romac force-pushed the romain/light-client-followup branch from edfc773 to d1a6357 Compare June 2, 2020 14:20
@romac romac force-pushed the romain/light-client-followup branch from 304efcc to cd38cf3 Compare June 5, 2020 10:42
@romac romac force-pushed the romain/light-client-followup branch from 0749e34 to 8b7a2aa Compare June 5, 2020 12:44
@romac romac mentioned this pull request Jun 5, 2020
5 tasks
@romac romac added the light-client Issues/features which involve the light client label Jun 5, 2020
@romac romac marked this pull request as ready for review June 9, 2020 08:38
@@ -1,14 +1,25 @@
use crate::prelude::*;
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe in the preamble provide reference to the english spec such that the invariants can be looked up by the reader.

Copy link
Member Author

Choose a reason for hiding this comment

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

@ebuchman suggested getting rid of the prelude entirely for better discoverability so that's perhaps not the right place to put those references. The crate-level documentation in lib.rs might be a better fit.

#[post(valid_schedule(ret, target_height, next_height, light_store))]
pub fn schedule(
#[post(valid_schedule(ret, target_height, current_height, light_store))]
pub fn basic_schedule(
Copy link
Contributor

Choose a reason for hiding this comment

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

Since this is actually performing bisection does it make sense to call it bisecting_schedule?

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure, that's indeed a better name. I chose basic here to express that this scheduler implementation does not do anything fancy for performance (like picking heights already present in the store, etc.)

Copy link
Member Author

@romac romac Jun 9, 2020

Choose a reason for hiding this comment

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

So perhaps basic_bisecting_schedule or something like that?

brapse
brapse previously approved these changes Jun 9, 2020
Copy link
Contributor

@brapse brapse left a comment

Choose a reason for hiding this comment

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

Great stuff. Tiny comments made but otherwise 👍

/// - i) If `latest_verified_height == current_height` and `latest_verified_height < target_height`
/// then `current_height < scheduled_height <= target_height`.
///
/// - ii) If `latest_verified_height < next_height` and `latest_verified_height < target_height`
Copy link
Contributor

Choose a reason for hiding this comment

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

s/next_height/current_height

///
/// ## Note
///
/// - Case i. captures the case where the light block at height nextHeight has been verified,
Copy link
Contributor

Choose a reason for hiding this comment

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

s/nextHeight/current_height

/// and we can choose a height closer to the targetHeight. As we get the `light_store` as parameter,
/// the choice of the next height can depend on the `light_store`, e.g., we can pick a height
/// for which we have already downloaded a light block.
/// - In Case ii. the header of `next_height` could not be verified, and we need to pick a smaller height.
Copy link
Contributor

Choose a reason for hiding this comment

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

same

/// - A commit validator
/// - A header hasher
///
/// For regular use, one can summon an implementation with `ProdVerifier::default()`.
Copy link
Contributor

Choose a reason for hiding this comment

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

s/summon/construct? 🧙

Copy link
Member Author

Choose a reason for hiding this comment

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

Right, the default instance is indeed not fancy enough to warrant such witchcraft ;)

liamsi
liamsi previously approved these changes Jun 9, 2020
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.

👍

// assert_eq!(iter.next_back(), Some(1));
// assert_eq!(iter.next_back(), None);
// }
// }
Copy link
Member

Choose a reason for hiding this comment

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

Why are these commented out? Maybe better to add a comment or delete.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah this test is currently disabled because it fails on CI as we don't have access to this temp dir. I need to read up a bit on the GitHub Actions infra to figure out how to specify a proper temp dir, so I will just add a comment in the meantime.

@romac romac dismissed stale reviews from liamsi and brapse via 72bc898 June 9, 2020 09:59
@romac
Copy link
Member Author

romac commented Jun 9, 2020

Thanks for the comments, just addressed them. Feel free to merge once CI goes through (modulo the test-integration-ignore job that's currently broken).

@liamsi
Copy link
Member

liamsi commented Jun 9, 2020

(modulo the test-integration-ignore job that's currently broken).

You should be able to merge the PR despite the failing integration tests (I think it's OK to ignore these for now).

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.

👍

@liamsi liamsi merged commit 393a2ef into master Jun 9, 2020
@liamsi liamsi deleted the romain/light-client-followup branch June 9, 2020 10:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
light-client Issues/features which involve the light client
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants