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

x/upgrade gRPC methods for VersionMap #9073

Merged
merged 71 commits into from
May 19, 2021
Merged

x/upgrade gRPC methods for VersionMap #9073

merged 71 commits into from
May 19, 2021

Conversation

technicallyty
Copy link
Contributor

@technicallyty technicallyty commented Apr 7, 2021

Description

+Adds gRPC definitions to query the VersionMap from x/upgrade store
+Adds CLI method for VersionMap gRPC query
+Adds cli_test.go file for testing VersionMap cli query
+Updates the swagger file with the new gRPC endpoint

This PR includes changes on unrelated proto files as a result of the proto formatter

closes: #8941


Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

  • Targeted PR against correct branch (see CONTRIBUTING.md)
  • Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • Code follows the module structure standards.
  • Wrote unit and integration tests
  • Updated relevant documentation (docs/) or specification (x/<module>/spec/)
  • Added relevant godoc comments.
  • Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
  • Re-reviewed Files changed in the Github PR explorer
  • Review Codecov Report in the comment section below once CI passes

@codecov
Copy link

codecov bot commented Apr 7, 2021

Codecov Report

Merging #9073 (e05c9c9) into master (ad49ec1) will decrease coverage by 0.17%.
The diff coverage is 87.27%.

❗ Current head e05c9c9 differs from pull request most recent head 40749ce. Consider uploading reports for the commit 40749ce to get more accurate results
Impacted file tree graph

@@            Coverage Diff             @@
##           master    #9073      +/-   ##
==========================================
- Coverage   60.30%   60.12%   -0.18%     
==========================================
  Files         588      590       +2     
  Lines       37001    37170     +169     
==========================================
+ Hits        22313    22349      +36     
- Misses      12711    12841     +130     
- Partials     1977     1980       +3     
Impacted Files Coverage Δ
x/upgrade/client/cli/query.go 22.22% <72.00%> (ø)
x/upgrade/keeper/grpc_query.go 74.07% <100.00%> (+15.25%) ⬆️
x/upgrade/keeper/keeper.go 79.60% <100.00%> (+3.09%) ⬆️
x/staking/types/msg.go 54.92% <0.00%> (-2.40%) ⬇️
x/staking/client/cli/tx.go 17.98% <0.00%> (ø)
x/upgrade/client/cli/tx.go 0.00% <0.00%> (ø)
x/staking/keeper/msg_server.go 0.45% <0.00%> (+0.01%) ⬆️

Copy link
Contributor

@amaury1093 amaury1093 left a comment

Choose a reason for hiding this comment

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

looks good, but we should probably avoid maps

proto/cosmos/upgrade/v1beta1/query.proto Outdated Show resolved Hide resolved
// RPC method.
message QueryVersionMapResponse {
// version_map is a map of module name to consensus version.
map<string, uint64> version_map = 1;
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, i'm a bit wary of this. With ADR-033, Query services are part of the state machine, so I would like to avoid maps altogether (looping through them is not deterministic).

Could we do repeated ModuleConsensusVersion, where is ModuleConsensusVersion is a message with 2 fields string and uint64? And then this array would be sorted by module name (similarly to how we sort sdk.Coins).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think there ends up being a trade-off here in terms of efficiency vs. safety against the novice module developer.

so if a module developer converts the map to an array for later storage, there is 100% chance that the next queried map won't have the same ordering.

we do add some overhead to the query though, as we have to convert the map to a slice, and then alphabetically sort the slice by module name. (i think thats like O(nlogn*m). this may be negligible for a small query like this though.

if we did go with returning a slice, it would probably be better to change the query name from VersionMap to something else (ModuleConsensusVersions?), since the underlying return type is no longer a Map.

curious if anyone else has thoughts - @aaronc ?

Copy link
Member

Choose a reason for hiding this comment

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

I would love to use protobuf maps, and I think it's safer to just use a repeated field instead. Using protobuf maps in APIs is something that will require its whole own "safety study" or something.

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. the current commit on this PR has the repeated field implemented. That just leaves the issue of the naming:

QueryVersionMap returning a slice would be a bit odd imo. I am thinking we can either

  1. rename it
  2. convert slice to map when request resolves in client

thoughts @aaronc @AmauryM ?

Copy link
Member

Choose a reason for hiding this comment

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

Let's call it QueryModuleVersions

Copy link
Contributor

Choose a reason for hiding this comment

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

QueryModuleVersions sounds good to me too

Copy link
Contributor Author

Choose a reason for hiding this comment

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

x/upgrade/client/cli/query.go Outdated Show resolved Hide resolved
x/upgrade/keeper/grpc_query.go Outdated Show resolved Hide resolved
@alessio alessio requested a review from fdymylja April 8, 2021 11:35
Copy link
Contributor

@amaury1093 amaury1093 left a comment

Choose a reason for hiding this comment

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

lgtm

x/upgrade/client/cli/query.go Outdated Show resolved Hide resolved
technicallyty and others added 2 commits May 17, 2021 08:13
Co-authored-by: Amaury <1293565+amaurym@users.noreply.github.com>
@technicallyty technicallyty requested a review from aaronc May 17, 2021 15:38
@@ -0,0 +1,114 @@
package cli_test
Copy link
Contributor

Choose a reason for hiding this comment

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

IntegrationTestSuite needs to be updated as per #6711

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

@aleem1314 aleem1314 left a comment

Choose a reason for hiding this comment

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

Preapproving

Copy link
Contributor

@atheeshp atheeshp left a comment

Choose a reason for hiding this comment

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

lgtm

@technicallyty technicallyty added the A:automerge Automatically merge PR once all prerequisites pass. label May 19, 2021
@mergify mergify bot merged commit 53fe03e into master May 19, 2021
@mergify mergify bot deleted the ty-8941-grpc_vm branch May 19, 2021 17:04
roysc pushed a commit to vulcanize/cosmos-sdk that referenced this pull request Jun 23, 2021
* setup version map query

* query methods

* grpc methods

* cleanup

* grpc for VersionMap

* swagger update

* swagger sync

* cleanup

* reset docs

* clean

* grpc with field

* daily

* -add grpc methods
-add optional field to get specific module from version map
-added cli test for version map query from cli

* -consolidate grpc test to one test function
-return better errors in grpc methods

* consolidate tests

* swagger update

* this breaks

* Try stringer on individual msgs

* change map to slice in proto

* cleanup

* add comments to proto fields

* cleanup

* regen proto files

* jsoncodec

* rename gRPC methods

* * add fetch method for module version slice
* add method to return version given a module name
* remove sorting functions

* lint

* Update proto/cosmos/upgrade/v1beta1/query.proto

Co-authored-by: Aaron Craelius <aaron@regen.network>

* Update proto/cosmos/upgrade/v1beta1/upgrade.proto

Co-authored-by: Aaron Craelius <aaron@regen.network>

* fix up comments and regen proto/swagger

* Update x/upgrade/client/cli/query.go

Co-authored-by: Amaury <1293565+amaurym@users.noreply.github.com>

* conform to pr 6711

* lint

Co-authored-by: technicallyty <48813565+tytech3@users.noreply.github.com>
Co-authored-by: Amaury M <1293565+amaurym@users.noreply.github.com>
Co-authored-by: Aaron Craelius <aaron@regen.network>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A:automerge Automatically merge PR once all prerequisites pass. C:CLI C:x/upgrade T:Docs Changes and features related to documentation.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add x/upgrade gRPC query for module VersionMap
5 participants