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

context: store commit info #748

Merged
merged 6 commits into from
Jun 13, 2019
Merged

context: store commit info #748

merged 6 commits into from
Jun 13, 2019

Conversation

ruseinov
Copy link
Contributor

Fixes #79
@ethanfrey Please validate that this is the right info.
I'm not sure if we want to customise any of that or use our own data structures.

@ruseinov ruseinov requested a review from ethanfrey June 10, 2019 11:46
@ruseinov ruseinov self-assigned this Jun 10, 2019
Copy link
Contributor

@ethanfrey ethanfrey left a comment

Choose a reason for hiding this comment

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

This is basically what I want, but can you convert the struct into a weave-specific one for the API?

context.go Outdated
@@ -72,6 +73,22 @@ func GetHeader(ctx Context) (abci.Header, bool) {
return val, ok
}

// WithCommitInfo sets the info on who signed the block in this Context.
// Panics if already set.
func WithCommitInfo(ctx Context, info abci.LastCommitInfo) Context {
Copy link
Contributor

Choose a reason for hiding this comment

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

I try not to use any abci/tendermint data structures in the weave internals to provide a loose coupling, also so all structs are documented in our codebase (I need to check this out, and follow imports into tendermint to even see what is in abci.LastCommitInfo).

Can you just make an abci.LastCommitInfo -> weave.CommitInfo helper as in genesis file, and then we can discuss if all fields are needed? Or anything else?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good to me, I wanted to validate the approach with you first.
I'm kind of ambivalent about the approach that should be taken, because our app is still pretty tightly coupled to tendermint in terms of interfaces/types it should support. One good reason to use tendermint structs is that when they change any of their types with tendermint upgrade - we get some if not all of that update for free.

In terms of digging to deps in order to see what they do, I guess I'm too spoiled using a fully fledged IDE to even notice, but it might definitely help a lot with IDEless PR reviews as well as means of documenting stuff. The downside is that we have to follow tendermints objects and duplicate the impl.

@ruseinov ruseinov marked this pull request as ready for review June 11, 2019 10:46
@ruseinov
Copy link
Contributor Author

@ethanfrey please take a look

@codecov-io
Copy link

Codecov Report

Merging #748 into master will decrease coverage by 0.1%.
The diff coverage is 5.2%.

Impacted file tree graph

@@           Coverage Diff            @@
##           master    #748     +/-   ##
========================================
- Coverage    66.4%   66.3%   -0.2%     
========================================
  Files         190     191      +1     
  Lines       10454   10473     +19     
========================================
+ Hits         6948    6949      +1     
- Misses       2680    2698     +18     
  Partials      826     826
Impacted Files Coverage Δ
helper.go 0% <0%> (ø)
context.go 64% <0%> (-10.5%) ⬇️
app/store.go 68.5% <100%> (+0.2%) ⬆️

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 758614c...864df77. Read the comment docs.

Copy link
Contributor

@ethanfrey ethanfrey left a comment

Choose a reason for hiding this comment

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

LGTM

Some ideas for enhancements, storing BlockInfo outside of context, but that is seriously out of scope of this PR. I like you decoupling types.


// CommitInfoFromABCI converts abci commit info to weave native type.
// This struct represents validator signatures on the current block.
func CommitInfoFromABCI(info abci.LastCommitInfo) CommitInfo {
Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, I am happy to have this a native weave type, even if we mirror their types.
Just to keep our API clean.

In the end, even if we do something like

type CommitInfo = abci.CommitInfo

and everyone imports weave.CommitInfo, then at least we decouple it there, so we could redefine CommitInfo in weave and then all packages use the new definition (complete with compile errors if there are inconsistent changes)

@@ -10,3 +12,22 @@ package weave;
message Metadata {
uint32 schema = 1;
}

// CommitInfo is basically a replica of tendermint commit info
Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, this is all abci stuff, can you use a similar approach in #747 to pull in the ValidatorUpdate struct?

Probably best to merge this PR first, then rebase #747 and do those API changes


// GetCommitInfo returns the info on validators that signed
// this block. Returns false if not present.
func GetCommitInfo(ctx Context) (CommitInfo, bool) {
Copy link
Contributor

Choose a reason for hiding this comment

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

It might be better to call it MustCommitInfo. There was similar issue with the BlockTime function that was renamed to MustBlockTime.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

sounds good to 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.

yeah, but I can't see this anywhere by the way, so leaving this as is for consistency. If we are about to change things up to Must we shall do it in one go I think.

@ruseinov ruseinov merged commit e5837d0 into master Jun 13, 2019
@ruseinov ruseinov deleted the feature/validators-ctx branch June 13, 2019 07:49
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.

Add validators that signed the block to context
4 participants