-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
chore: added new field account-id
with uint64 in AccountAddressByID
#13780
Conversation
account-id
with uint64 in AccountAddressByID
account-id
with uint64 in AccountAddressByID
@@ -197,10 +197,17 @@ message AddressStringToBytesResponse { | |||
// | |||
// Since: cosmos-sdk 0.46.2 | |||
message QueryAccountAddressByIDRequest { | |||
// Deprecated, use account_id instead | |||
// | |||
// id is the account number of the address to be queried. This field | |||
// should have been an uint64 (like all account numbers), and will be | |||
// updated to uint64 in a future version of the auth query. | |||
int64 id = 1; |
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.
we can add the proto deprecated annotation here
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #13780 +/- ##
=======================================
Coverage 56.24% 56.24%
=======================================
Files 664 664
Lines 56480 56484 +4
=======================================
+ Hits 31766 31769 +3
- Misses 22143 22144 +1
Partials 2571 2571
|
x/auth/keeper/grpc_query.go
Outdated
|
||
var accId uint64 | ||
switch { | ||
case req.AccountId > 0 && req.Id > 0 && req.AccountId != uint64(req.Id): |
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.
TBH I'm not sure how much value this case adds. IMO we should instead enforce one or the other value is passed. If both are passed, i.e. both are non-zero, then simply error.
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.
IMO we should instead enforce one or the other value is passed
Unforunately we can't do this since 0
is also a valid case here to query by account-number
. and the default values for both int64
& uint64
are 0
s
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.
We start account numbers at 1?
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'm not sure, but I'm getting the response for 0
too by using the same query.
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.
Yeah I see that they start with 0
. It' really unfortunate we have to have this sort of case. I would almost prefer to completely omit/ignore the legacy field all together.
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 also agree with ignoring the legacy field. Maybe we can throw an error if it's not zero? So that users have immediate feedback they need to change something on their side.
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.
we are keeping it as deprecated means, may be it should not throw error unitl the field gets removed right? (not sure just a thought)
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.
The question really is:
Are we backporting this to < 0.47.x? If not, then just ignore the legacy field and remove this case all together. If we are backporting to 0.46.x and 0.45.x, then we need to handle the use of the legacy field and I suppose this is fine.
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 vote no backport.
Edit: but again, I also don't like to ignore that old field. Imagina a dapp pinging that endpoint, and suddently (after node upgrade) it returns a different response. I propose to error if the legacy field is populated.
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.
The problem is a zero/default value 0
is technically valid (the very first account). So there is no notion of "set" vs "unset" unfortunately. Thats why I suggested ignoring it.
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.
LGTM, just a small proposal to have shorter code
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.
few nits
Co-authored-by: Likhita Polavarapu <78951027+likhita-809@users.noreply.github.com>
Co-authored-by: Likhita Polavarapu <78951027+likhita-809@users.noreply.github.com>
Co-authored-by: Likhita Polavarapu <78951027+likhita-809@users.noreply.github.com>
…into ap/change-acc-id-type
[Cosmos SDK] SonarCloud Quality Gate failed. |
@Mergifyio backport release/v0.47.x |
✅ Backports have been created
|
…D` (#13780) * add changes * Update CHANGELOG.md * Update CHANGELOG.md * review changes * add test * fix static check * fix lint * fix lint * fix lint * review changes * review changes * review changes * review changes * fix tests * Update CHANGELOG.md Co-authored-by: Likhita Polavarapu <78951027+likhita-809@users.noreply.github.com> * Update CHANGELOG.md Co-authored-by: Likhita Polavarapu <78951027+likhita-809@users.noreply.github.com> * Update proto/cosmos/auth/v1beta1/query.proto Co-authored-by: Likhita Polavarapu <78951027+likhita-809@users.noreply.github.com> * review changes * lint * review changes Co-authored-by: Likhita Polavarapu <78951027+likhita-809@users.noreply.github.com> (cherry picked from commit 42597ee)
Description
Closes: #13410
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 API or client breaking changeCHANGELOG.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