-
Notifications
You must be signed in to change notification settings - Fork 341
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
Add query for the total supply of a coin #1356
Conversation
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, although you need to include tests for that query_supply
helper because otherwise coverage won't pass it through.
@ueco-jb thanks, will do. i did not include it because other bank query helpers (e.g. |
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.
Very nice. Could you add an entry to the Unreleased section of the CHANGELOG.md?
We need to think about more about how this breaks users but overall it looks solid.
packages/std/src/query/bank.rs
Outdated
#[serde(rename_all = "snake_case")] | ||
pub struct SupplyResponse { | ||
/// Always returns a Coin with the requested denom. | ||
/// This may be of 0 amount if no such funds. |
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.
Do we also get 0 in case the denom does not exist at all? Or would that be an error. I think we should specify that.
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 get a zero, because this is what BankKeeper.GetSupply
does. will add a sentence on this
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.
Co-authored-by: Simon Warta <[email protected]>
@webmaster128 pls see the changes made according to your comments |
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.
Nice work, thank you!
The only question left for me is what happens to users that use 1.1 contracts with this query on 1.0 chains that don't have the implementation. Their contracts will fail at runtime.
Given that it will take a while until contract devs pick up the new query and chains are hungy for upgrades, it does not seem to be a big issue. Also people thoroughly test their contracts on a testnet, right? 😉
We could add a feature flag for this but it would be heavy lifting. Also FEATURES.md documents
A good feature makes sense to be disabled. [...]
When functionality is always present in the VM (such as a new import implemented
directly in the VM, see [#1299]), we should not use features. They just create
fragmentation in the CosmWasm ecosystem and increase the barrier for adoption.
Instead thecheck_wasm_imports
check is used to validate this when the
contract is stored.
While the motivation to not create a new feature here is valid, we don't have a check in place when uploading the contract.
Shouldn't this PR be marked as breaking then and released with minor? |
The next release will be 1.1, so there is some signaling in the version number. Regarding "breaking", that can mean so many things in our context. This PR will not break source code or existing compiled constracts and will not affact the vast majority of users. Also there is nothing wrong with failing at runtime when a new query is used the chain does not yet support. It's just not the most convenient thing possible. |
Alright. In that case I'd maybe at least add some disclaimer, that it will fail at runtime for older versions. |
so the i'm wondering if it's possible to assert |
The marker export It would be a solution. But if we start using the features mechanism for all those small incremental improvements that are not meant to be deactivated long term, then we pollute the features list a lot. |
This is the best approach to compatibility I can think of right now. If you disagree, feel free to continue the discussion in that ticket. From my side this PR is good to get merged. Can you resolve the conflicts? |
hi @webmaster128 sorry for the lack of actions on this PR. have been incredibly busy the last 2 weeks. the conflicts have been resolved, but i see there still isn't a clear agreement in the discussion #1367 this being said, can you also review these two PRs, which are prerequisites for this one to work: |
Hey Larry, after some internal discussions we concluded that this case fits well into the capabilities concept and we can create a cosmwasm_1_1 capability. This makes it possible to ship this work in the next release. I guess the reflect contract can be used to test this new query ( |
@larry0x Tom is taking over this PR if you don't mind. Thanks again. |
I was just updating this PR and resolving conflicts; I'll try to add the capability stuff in a separate PR targeting this one |
Hi @uint @webmaster128 i certainly don't mind. Tbh i don't know what's the approach Confio is taking towards breaking API changes like this, so it's better you guys handle it. Please be reminded that there are two other PRs in wasmvm and wasmd which are prerequisites for this one to work. |
Alright, the "PR into this PR" option doesn't seem feasible. I'll just push here. Thanks, @larry0x! |
This probably needs updating too: I'll figure it out tomorrow. |
currently it is not possible to query the total supply of a native SDK coin. this is something that protocols often need to do, especially that now contract are able to mint native coins thanks to the
tokenfactory
module. this PR adds the binding for this query type.see also: