-
Notifications
You must be signed in to change notification settings - Fork 122
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
refactor: clean protos for clarity #1071
Conversation
import "google/protobuf/timestamp.proto"; | ||
|
||
// | ||
// Note any type defined in this file is referenced/persisted in both the consumer and provider CCV modules, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TLDR most consumer protos are persisted on provider, so most ended up in this file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All these consumer protos are nil for new consumer chains and only populated in the consumer genesis state when the chain is restarted (on export/import). IIRC, the provider only needs to store the consumer genesis for new chains. It would be good to differentiate between this two scenarios and have all these ptotos local to the consumer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see where you're coming from, but from a pure dependency perspective, the consumer's genesis state struct is referenced by both the consumer and provider modules. Any type that's a field in that struct must also be referenced by both modules, even if nil.
There's some ways we could untangle these cross dependancies, like creating a new struct that'd be spit out of MakeConsumerGenesis
for the provider, and making that a field in the consumer's true GenesisState struct. But there's complexities in how the consumer genesis JSON would be constructed.
This PR is mostly intended to illuminate dep issues rather than fix them all, and it should stay as a true refactor
ccv.ConsumerPacketDataList{}, | ||
types.LastTransmissionBlockHeight{}, | ||
false, | ||
Params: params, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was required to add keys to struct fields in this file to appease linter
@mpoke @MSalopek does a change like this warrant incrementing the protobuf version number from v1? See proto package names like |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work @smarshall-spitzbart. I really like the idea of this. See my comments bellow.
import "google/protobuf/timestamp.proto"; | ||
|
||
// | ||
// Note any type defined in this file is referenced/persisted in both the consumer and provider CCV modules, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All these consumer protos are nil for new consumer chains and only populated in the consumer genesis state when the chain is restarted (on export/import). IIRC, the provider only needs to store the consumer genesis for new chains. It would be good to differentiate between this two scenarios and have all these ptotos local to the consumer.
@@ -158,7 +158,7 @@ func (k Keeper) ExportGenesis(ctx sdk.Context) *types.GenesisState { | |||
k.GetAllValsetUpdateBlockHeights(ctx), | |||
consumerStates, | |||
k.GetAllUnbondingOps(ctx), | |||
&ccv.MaturedUnbondingOps{Ids: k.GetMaturedUnbondingOps(ctx)}, | |||
&types.MaturedUnbondingOps{Ids: k.GetMaturedUnbondingOps(ctx)}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use cvvtypes for more clarity. Please apply throughout the repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fully agree that we should use the ccvtypes
alias everywhere, instead of types
or ccv
. However I don't think that sort of change is appropriate for this PR as we're already at 4k lines of changes.
Making the alias change in this file would add ~14 lines from the look of it, but other files have even more refs to the undesirable aliases
@@ -262,7 +261,7 @@ func TestOnChanOpenAck(t *testing.T) { | |||
{ | |||
"invalid: mismatched serialized version", | |||
func(keeper *consumerkeeper.Keeper, params *params, mocks testkeeper.MockedKeepers) { | |||
md := providertypes.HandshakeMetadata{ | |||
md := ccv.HandshakeMetadata{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we have ccv "github.com/cosmos/interchain-security/v3/x/ccv/types"
here and not simply"github.com/cosmos/interchain-security/v3/x/ccv/types"
as in ibc_module.test.go
. Does this lead to inconsistencies between ibc_module.go
and ibc_module_test.go
, e.g., we have ccv.HandshakeMetadata
here instead of types.HandshakeMetadata
in ibc_module.go
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #1071 (comment), the type aliases in this repo are very inconsistent and this does lead to inconsistencies, but I don't think it's worth fixing all in this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 I agree. We can create another PR for fixing naming inconsistencies across all the files, just so we don't forget.
@@ -12,6 +12,7 @@ import ( | |||
|
|||
testkeeper "github.com/cosmos/interchain-security/v3/testutil/keeper" | |||
"github.com/cosmos/interchain-security/v3/x/ccv/consumer/types" | |||
ccvtypes "github.com/cosmos/interchain-security/v3/x/ccv/types" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similarly to my previous comment, there seems the naming is consistent between distribution.go
and distribution_test.go
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See above
message HandshakeMetadata { | ||
string provider_fee_pool_addr = 1; | ||
string version = 2; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is my understanding correct that the reward distribution is performed through a MsgTransfer
message and hence why we do not see something reward-related in this file? If yes, it might make sense to add a comment here to point to this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea consumer rewards are sent through a distribution channel, whereas wire.proto is for schemas sent over a ccv channel, this comment can hopefully help
import "google/protobuf/timestamp.proto"; | ||
|
||
// | ||
// Note any type defined in this file is referenced/persisted in both the consumer and provider CCV modules, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: reading this referenced/persisted in both the consumer and provider CCV modules,
I would have expected the file to be called shared.proto
. My understanding is the file is called shared**_consumer**.proto
because it contains only consumer-related types used by the consumer but also referenced by the provider. If that's the case, might make sense to clarify in the comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this scenario, the file contains only consumer-related types used by the consumer but also referenced by the provider. This happens to also be the same set of types that are more generally shared between consumer/provider.
I can add a comment with this sort of this thing, or maybe it's worth clarifying once #1214 is completed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 So, I guess if this file would radically change as part of #1214, then we can skip any changes here.
x/ccv/consumer/keeper/params.go
Outdated
@@ -6,8 +6,7 @@ import ( | |||
sdk "github.com/cosmos/cosmos-sdk/types" | |||
stakingtypes "github.com/cosmos/cosmos-sdk/x/staking/types" | |||
|
|||
"github.com/cosmos/interchain-security/v3/x/ccv/consumer/types" | |||
ccvtypes "github.com/cosmos/interchain-security/v3/x/ccv/types" | |||
types "github.com/cosmos/interchain-security/v3/x/ccv/types" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Related to the comment. I guess in these cases we can use ccvtypes
even in this PR since the name is already changed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well the code that was previously in "github.com/cosmos/interchain-security/v3/x/ccv/consumer/types" is now in "github.com/cosmos/interchain-security/v3/x/ccv/types", so originally using the types
alias here avoids a big diff. But I'll make the change since we're already talking about it 065c2cd
@@ -16,8 +16,7 @@ import ( | |||
tmtypes "github.com/cometbft/cometbft/types" | |||
|
|||
"github.com/cosmos/interchain-security/v3/testutil/crypto" | |||
"github.com/cosmos/interchain-security/v3/x/ccv/consumer/types" | |||
ccv "github.com/cosmos/interchain-security/v3/x/ccv/types" | |||
types "github.com/cosmos/interchain-security/v3/x/ccv/types" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Related to the comment. I guess in these cases we can use ccvtypes
even in this PR since the name is already changed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Making the alias change here would increase PR diff size by 122 lines, so I'd again encourage this for a separate PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left some additional nit comment, but in general looks good to me, so approving.
Thanks for working on this Shawn!
* docs: add testing improvements ADR (adr-011) (#1197) * docs: add testing improvements ADR * docs: fix links and typos * Update docs/docs/adrs/adr-011-improving-test-confidence.md Co-authored-by: Shawn <[email protected]> * Update docs/docs/adrs/adr-011-improving-test-confidence.md Co-authored-by: Shawn <[email protected]> * docs: update from comments --------- Co-authored-by: Shawn <[email protected]> * refactor: clean protos for clarity (#1071) * consumer proto folder * provider comments, move one msg * ccv comments * moved shiz * proto changes to build * make proto gen again * no circ dep * Update wire.proto * comments * dun builds * progress save * FIN * refactors * rm improper proto ref * rm todos, issue now * lint till I die * update comments, rebuild protos * change ccv.go to wire.go, and test file * consistent comment * Update wire.proto * example alias diff --------- Co-authored-by: MSalopek <[email protected]>
Description
Closes: #1072
Achieves:
Note this PR also contributes toward #801, in that we're reducing the amount of cross dependancies between the consumer ccv module and the provider ccv module. The end goal is that all shared dependancies live within
x/ccv/types
, thenx/ccv/provider
and/x/ccv/consumer
do no reference one another. This is surely possible, but not easy and a huge source of tech debt.Notes:
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...
!
to the type prefix if state-machine breaking change (i.e., requires coordinated upgrade)CHANGELOG.md
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...
!
in the type prefix if API or client breaking change