Skip to content
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

Merged
merged 28 commits into from
Aug 29, 2022
Merged

Add query for the total supply of a coin #1356

merged 28 commits into from
Aug 29, 2022

Conversation

larry0x
Copy link
Contributor

@larry0x larry0x commented Jul 12, 2022

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:

Copy link
Contributor

@ueco-jb ueco-jb left a 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.

@larry0x
Copy link
Contributor Author

larry0x commented Jul 13, 2022

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. query_balance) don't have corresponding unit tests either

Copy link
Member

@webmaster128 webmaster128 left a 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 Show resolved Hide resolved
#[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.
Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@larry0x
Copy link
Contributor Author

larry0x commented Jul 14, 2022

@webmaster128 pls see the changes made according to your comments

Copy link
Member

@webmaster128 webmaster128 left a 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 the check_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.

@ueco-jb
Copy link
Contributor

ueco-jb commented Jul 14, 2022

Their contracts will fail at runtime.

Shouldn't this PR be marked as breaking then and released with minor?

@webmaster128
Copy link
Member

webmaster128 commented Jul 14, 2022

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.

@ueco-jb
Copy link
Contributor

ueco-jb commented Jul 14, 2022

Alright. In that case I'd maybe at least add some disclaimer, that it will fail at runtime for older versions.

@larry0x
Copy link
Contributor Author

larry0x commented Jul 14, 2022

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.

so the osmo-bindings library asserts that any contract importing it can only be run on the osmosis chain by having this line: https://github.com/osmosis-labs/bindings/blob/v0.6.0/packages/bindings/src/lib.rs#L11-L14

i'm wondering if it's possible to assert wasmd version the same way?

@webmaster128
Copy link
Member

webmaster128 commented Jul 14, 2022

The marker export extern "C" fn requires_* is one part of the features mechanism described in https://github.com/CosmWasm/cosmwasm/blob/main/docs/FEATURES.md.

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.

@webmaster128 webmaster128 added this to the 1.1.0 milestone Jul 16, 2022
@webmaster128 webmaster128 mentioned this pull request Jul 16, 2022
3 tasks
@webmaster128
Copy link
Member

webmaster128 commented Jul 16, 2022

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?

@larry0x
Copy link
Contributor Author

larry0x commented Jul 29, 2022

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:

@uint uint removed this from the 1.1.0 milestone Aug 9, 2022
@webmaster128 webmaster128 added this to the 1.1.0 milestone Aug 17, 2022
@webmaster128
Copy link
Member

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 (QueryMsg::Chain). But not sure.

@webmaster128
Copy link
Member

@larry0x Tom is taking over this PR if you don't mind. Thanks again.

@uint
Copy link
Contributor

uint commented Aug 23, 2022

I was just updating this PR and resolving conflicts; I'll try to add the capability stuff in a separate PR targeting this one

@larry0x
Copy link
Contributor Author

larry0x commented Aug 23, 2022

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.

@uint
Copy link
Contributor

uint commented Aug 23, 2022

Alright, the "PR into this PR" option doesn't seem feasible. I'll just push here. Thanks, @larry0x!

@uint
Copy link
Contributor

uint commented Aug 23, 2022

This probably needs updating too:
https://github.com/CosmWasm/cosmwasm/blob/main/packages/std/src/mock.rs#L455

I'll figure it out tomorrow.

@uint uint requested a review from webmaster128 August 24, 2022 12:05
@uint uint merged commit a9ae6fa into CosmWasm:main Aug 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants