-
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
feat: implement nft module msg server #10074
Conversation
Codecov Report
@@ Coverage Diff @@
## master #10074 +/- ##
==========================================
+ Coverage 64.19% 64.44% +0.24%
==========================================
Files 575 579 +4
Lines 54923 54901 -22
==========================================
+ Hits 35257 35380 +123
+ Misses 17663 17509 -154
- Partials 2003 2012 +9
|
Any updates on this @ryanchristo @clevinson ? |
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.
Looks good!
- let's move the generated proto code to a separate module. I propose
x/nft/proto
. The reason is related to the semver discussion for Cosmos SDK, and versioning proto definition is one of the requirements. We will do that work for all other modules right after 0.45 release. - let's add integration tests on the proto service level (can be done in a separate PR - we will just need to create a task for it - leaving it to you).
- we should avoid panics and
Must*
methods whenever possible. - also, I would consider dropping the
beta
name in the proto versions. This doesn't help with versioning in fact. Once it will be used it should not havebeta
(let's add it to the issue tracker).
type AccountKeeper interface { | ||
GetModuleAddress(name string) sdk.AccAddress | ||
GetAccount(ctx sdk.Context, addr sdk.AccAddress) authtypes.AccountI | ||
} |
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.
would be good to depend on Query
proto services rather than keepers directly, but I think we will firstly need to clean other parts of SDK before requesting that changes (and finalize adr-33).
Id: msg.Id, | ||
Sender: msg.Sender, | ||
Receiver: msg.Receiver, | ||
}) |
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.
👍
just for clarity: this was decided in the SDK grooming meeting that this change is not necessary for the PR to be merged |
Yes. Definitely not blocking. IMHO it's good to do it though, because we will already separate more stable proto (which external clients will be able to consume) from the functional implementation. And it's very easy to do that split at this stage when no other external app is depending on 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.
Some comments as I was going through this today. Didn't fully finish, but going OOO so wanted to post what I have so far.
Thanks for this work!
…plement-nft-msgServer
When I tried to move the generated proto file to the x/nft/proto package, I encountered the following problems:
Do you have any good solutions to the above problems? |
Your mint method checks if the class of the minted nft exists, but there's no msg to create new class. So how can user mint new nft ? |
According to the design of |
ohh, I get it now, thank u |
@dreamer-zq , the previous question shows that we should better explain that in the ADR. Could you add a paragraph in the ADR highlighting what client module must provide (at minimum)? |
We are in fact discussing solutions on the future migration of the core modules. We don't have a plan finalized yet. If you encounter some problems, then you can skip it and we will try to refactor it later.
We have few ideas, but non of them is finalized (eg: wrappers, implementer function as an attribute)... you could include the implementation in the proto package... but again - if this will cause some doubts then let's skip it.
You can add a method in |
I advise that we pause refactoring generated proto code into separate go modules here. I think our team should lead doing this refactoring once we've figured out a strategy, and this should be done in a separate PR. We should also use the |
I have added some instructions in adr-33 |
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.
Left few more comments.
Most importantly, we need to implement UnpackInterfaces
for the NFT type.
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 good! Thanks for the PR!
Happy to merge this. Can someone take a look at the test failures? |
What's up with CI? @robert-zaremba @AmauryM ? We really need to fix these issues. Is there anything in CI actually preventing this from being merged? Also is this go module actually getting tested in CI? |
There's a couple of flaky tests #9010. No-one has found their root cause yet. The current way we're circumventing this is by re-running the tests, which I just did |
<!-- The default pull request template is for types feat, fix, or refactor. For other templates, add one of the following parameters to the url: - template=docs.md - template=other.md --> ## Description MsgServer implementation and corresponding keeper methods, refer cosmos#9826 <!-- Add a description of the changes that this PR introduces and the files that are the most critical to review. --> --- ### 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/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) - [ ] 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` - [ ] 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)
Description
MsgServer implementation and corresponding keeper methods, refer #9826
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