-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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/auth/types: CountSubKeys inexplicably returns 1 when the public key isn't of type multisig.PubKeyMultisigThreshold yet naturally counts otherwise #6889
Comments
A non-multisig, i.e. a regular signature, it naturally a count of 1. If it is a multisig, then it recursively calls it on its pubkeys. The number one isn't magic here. |
Is this just missing a test @odeke-em ? The logic looks correct to me. |
It could use a comment as to why that 1, and a test of sorts indeed would
be nice but just the comment that Aleksander explaining that logic would
suffice for me.
…On Thu, Jul 30, 2020 at 7:34 AM Aaron Craelius ***@***.***> wrote:
Is this just missing a test @odeke-em <https://github.com/odeke-em> ? The
logic looks correct to me.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6889 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABFL3V3T6L6JDLKDNZRKBZDR6GAJBANCNFSM4PMYTG7Q>
.
|
Is recursive function lingo, returning |
@odeke-em can we close this one? there are some test cases for this in here |
## Description Closes: #6889 #15056 --- ### 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](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] added `!` to the type prefix if API or client breaking change - [ ] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#pr-targeting)) - [ ] provided a link to the relevant issue or specification - [ ] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/main/docs/docs/building-modules) - [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#testing) - [ ] added a changelog entry to `CHANGELOG.md` - [ ] included comments for [documenting Go code](https://blog.golang.org/godoc) - [ ] 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](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) 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)
The code in question is
cosmos-sdk/x/auth/types/stdtx.go
Lines 128 to 140 in 72ebafe
Why does it return the magic number 1 if pub is not of the required yet, yet in the positive case is actually recursively counts subkeys. I don't see a test to affirm this behavior and could perhaps return random behavior. If this logic is intended, at least let's document it.
For Admin Use
The text was updated successfully, but these errors were encountered: