Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix: non consistent keyring (#10844)
## Description Normally keyring module creates two record for each public key created in keyringdb. The first one with an address as a key witch contains only name of the second key, wich actually contains a public key ![Screenshot_20211227_173827](https://user-images.githubusercontent.com/62722506/147482783-ffd495e6-7f16-4497-b1a3-50e9db90e1e8.png) But a couple of times we have faced an issue, when the first record exists, and the second for some reason does not. ![Screenshot_20211227_173846](https://user-images.githubusercontent.com/62722506/147482893-ffe159fd-9eeb-493f-a9db-75c7ccedbf80.png) In such case you are unable to import public key due to error ```shell $ go run ./cmd/terrad/ keys --keyring-backend kwallet add swelf --pubkey '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"Ap1W7ww/FaZVpAd487QUVXh7Nmxk4FlREr5IGPuzEnJu"}' Error: public key already exists in keybase ``` in the same time terrad cli do not see any keys in the keyring ```shell $ go run ./cmd/terrad/ keys --keyring-backend kwallet list [] ``` The error occurs when the record with address still exists in the keyring db. I would like to resolve the error. I see at least three different ways to do it. 1) Informing the user about situation and recreate public key ```shell $ go run ./cmd/terrad/ keys --keyring-backend kwallet add swelf --pubkey '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"Ap1W7ww/FaZVpAd487QUVXh7Nmxk4FlREr5IGPuzEnJu"}' **address "7cc4633deb18c0531b382a50275ad94e05f84580" exists but pubkey itself does not recreating pubkey record** - name: swelf type: offline address: terra10nzxx00trrq9xxec9fgzwkkefczls3vqkpkjl4 pubkey: '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"Ap1W7ww/FaZVpAd487QUVXh7Nmxk4FlREr5IGPuzEnJu"}' mnemonic: "" ``` with notifying user about an issue 2) Asking the user to confirm procedure of restoring public key 3) Just informing user about an issue and do nothing. I prefer the first way, i do not see a reason when user do not want to fix an issue. --- ### 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... - [x] 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 - [x] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/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/master/docs/building-modules) - [x] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing) - [ ] added a changelog entry to `CHANGELOG.md` - [x] 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)
- Loading branch information