-
Notifications
You must be signed in to change notification settings - Fork 138
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
fix: permissionless added event + cli changes #2185
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -201,7 +201,7 @@ func (k Keeper) QueryValidatorProviderAddr(goCtx context.Context, req *types.Que | |
} | ||
consumerAddr := types.NewConsumerConsAddress(consumerAddrTmp) | ||
|
||
providerAddr, found := k.GetValidatorByConsumerAddr(ctx, req.ChainId, consumerAddr) | ||
providerAddr, found := k.GetValidatorByConsumerAddr(ctx, req.ConsumerId, consumerAddr) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nice catch. @insumity why do we have deprecated fields in query requests. Given that both chanId and consumerId have the same type, it's easy to have bugs where we call functions with a chainId. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For backward compatibility. We try to prevent
But in this case we unfortunately missed it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Can you please give more details about this. What's the use case that we want to keep compatibility with? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We could imagine that Hermes is using this query ( There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Bumping the proto version is something we should talk to @MSalopek. Regarding breaking the queries for Hermes for example, as you stated it will be broken anyway. All the users of these queries will need to update their code. Leaving chainId there seems even more dangerous to me as there is a chance that we forget to return an error and the query goes through and returns weird stuff. So my recommendation would be to remove deprecated fields from the queries. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would avoid |
||
if !found { | ||
return &types.QueryValidatorProviderAddrResponse{}, nil | ||
} | ||
|
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.
How will the user differentiate between the json they need to provide for create-consumer and the one for update-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.
right, we need to provide an example.
I can also imagine to have the common part's in a json file (e.g. metadata, init-, powershaping-parameters) and those which differ as mandatory/optional arguments (optional would be 'new_owner').
If you're ok I'll keep this change for later once we have a preference.
In any case we'll end up with a 'one-file solution' I'd say.
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.
This just needs an update to the instructions.
All json fields have
omitempty
tag.