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

feat: add message option extension to signal msg signers in a language agnostic way #10977

Merged
merged 23 commits into from Jan 28, 2022

Conversation

fdymylja
Copy link
Contributor

Description

Closes: #10933


Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

  • included the correct type prefix in the PR title
  • added ! to the type prefix if API or client breaking change
  • targeted the correct branch (see PR Targeting)
  • provided a link to the relevant issue or specification
  • followed the guidelines for building modules
  • included the necessary unit and integration tests
  • added a changelog entry to CHANGELOG.md
  • included comments for documenting Go code
  • updated the relevant documentation or specification
  • reviewed "Files changed" and left comments if necessary
  • confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

  • confirmed the correct type prefix in the PR title
  • confirmed ! in the type prefix if API or client breaking change
  • confirmed all author checklist items have been addressed
  • reviewed state machine logic
  • reviewed API design and naming
  • reviewed documentation is accurate
  • reviewed tests and test coverage
  • manually tested (if applicable)

@fdymylja fdymylja changed the title add: message option extension to signal msg signers in a language agnostic way feat: message option extension to signal msg signers in a language agnostic way Jan 19, 2022
@fdymylja
Copy link
Contributor Author

This PR includes only proto changes and generated code changes.

I have already written the code that does runtime check but I haven't pushed it yet.

The runtime code asserted that every signer is correctly formed.

The only thing I'd need right now for the review is to make sure that cosmos.msg.signer marks the correct field as the GetSigners() implementation.

I mean I've checked it multiple times but an extra pair of eyes helps.

@fdymylja fdymylja changed the title feat: message option extension to signal msg signers in a language agnostic way feat: add message option extension to signal msg signers in a language agnostic way Jan 19, 2022
@codecov
Copy link

codecov bot commented Jan 19, 2022

Codecov Report

Merging #10977 (025e02a) into master (95e65fe) will decrease coverage by 0.11%.
The diff coverage is 79.76%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master   #10977      +/-   ##
==========================================
- Coverage   65.95%   65.84%   -0.12%     
==========================================
  Files         647      644       -3     
  Lines       65873    65630     -243     
==========================================
- Hits        43444    43211     -233     
+ Misses      19941    19939       -2     
+ Partials     2488     2480       -8     
Impacted Files Coverage Δ
crypto/armor.go 83.08% <ø> (ø)
x/gov/keeper/grpc_query.go 73.01% <ø> (-0.29%) ⬇️
x/gov/keeper/vote.go 92.50% <ø> (+2.17%) ⬆️
x/gov/types/v1beta2/msgs.go 63.69% <ø> (ø)
x/nft/keeper/grpc_query.go 69.38% <60.41%> (-1.51%) ⬇️
crypto/xsalsa20symmetric/symmetric.go 65.71% <65.71%> (ø)
x/upgrade/abci.go 92.15% <84.61%> (-2.58%) ⬇️
x/nft/keeper/keys.go 96.22% <90.90%> (-3.78%) ⬇️
x/gov/abci.go 90.29% <100.00%> (-2.92%) ⬇️
x/gov/keeper/tally.go 91.20% <100.00%> (ø)
... and 15 more

@fdymylja
Copy link
Contributor Author

Anyone knows why this test might be failing? First time seeing this.

https://github.com/cosmos/cosmos-sdk/runs/4868894745?check_suite_focus=true

// The field must either be of string kind, or of message
// kind in case the signer information is contained within
// a message inside the cosmos message.
repeated string signers = 11110000;
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
repeated string signers = 11110000;
repeated string signer = 11110000;

This is more intuitive naming given how repeated options are declared

@@ -0,0 +1,22 @@
syntax="proto3";

package cosmos.msg.v1beta1;
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
package cosmos.msg.v1beta1;
package cosmos.msg.v1beta1;

Let's change this to v1 before release (or change it now)

@fdymylja
Copy link
Contributor Author

Tests added, and added more docs.

We have no real way to test the protoregistry part due to how gogoproto registry works.

The policy in case of missing/malformed signers is a panic.

I was wondering if we should relax it or use a global to set it from panic to warning, reason being unexpected panics due to some unforeseen errors in the registry.

cc: @aaronc, @AmauryM

@fdymylja
Copy link
Contributor Author

Putting on draft again in order to try to resolve protobuf filenames conflicts in a more elegant way.

@fdymylja fdymylja marked this pull request as draft January 25, 2022 11:56
@aaronc
Copy link
Member

aaronc commented Jan 25, 2022

What if we just merge the annotations in this PR and deal with the validation in a follow up?

# Conflicts:
#	x/gov/types/v1beta2/tx.pb.go
@github-actions github-actions bot removed the C:orm label Jan 27, 2022
@fdymylja fdymylja marked this pull request as ready for review January 27, 2022 13:53
@fdymylja
Copy link
Contributor Author

Opening this again for review, removed the validation part as doing the gogoproto registry fix alongside this PR requires too much dependency synchronisation.

cc: @aaronc, @AmauryM, @marbar3778

Copy link
Member

@tac0turtle tac0turtle left a comment

Choose a reason for hiding this comment

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

utACK

Comment on lines +14 to +15
storetypes "github.com/cosmos/cosmos-sdk/store/types"

Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
storetypes "github.com/cosmos/cosmos-sdk/store/types"
storetypes "github.com/cosmos/cosmos-sdk/store/types"

// if validator_address == delegator_address then only one
// is expected to sign, otherwise both are.
option (cosmos.msg.v1.signer) = "delegator_address";
option (cosmos.msg.v1.signer) = "validator_address";
Copy link
Contributor

Choose a reason for hiding this comment

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

What do you think of option (cosmos.msg.v1.signer) = "delegator_address,validator_address"; which would be similar to e.g. the orm indices syntax

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Considering the instances in which we have multiple signers, I'd keep it this way, also because the decision to rename the field signers to signer was mainly driven by the most common use case.

But no strong opinion otherwise, let me know.

@aaronc
Copy link
Member

aaronc commented Jan 28, 2022

I'd like to take some time in today's architecture call to present this and other pulsar/app wiring related changes that are coming

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

proposal: add a new MessageOption extension in signing to mark messages expected signers.
4 participants