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

Locked state of contracts return consistent response #93

Closed
Tracked by #85
Anmol1696 opened this issue Jul 10, 2023 · 3 comments · Fixed by #94
Closed
Tracked by #85

Locked state of contracts return consistent response #93

Anmol1696 opened this issue Jul 10, 2023 · 3 comments · Fixed by #94

Comments

@Anmol1696
Copy link
Contributor

Overview

When contracts are in locked state, they should return that information in a consistent way for all contracts.

Currently

external-staking contract returns an error on undelegate msg:

smart query error (ignored): rpc error: code = Unknown desc = Value is already write locked: query wasm contract failed: unknown request

While it on delegate it returns query response of locked: {}. Which is more consistent.

Proposal

If contract is is locked state, it should not return an error, but a response of locked: {}.

@maurolacy
Copy link
Collaborator

maurolacy commented Jul 12, 2023

Thanks for reporting this. Will fix it asap.

@maurolacy
Copy link
Collaborator

maurolacy commented Jul 14, 2023

Was taking a look at the relevant methods (external-staking's receive_virtual_stake and unstake) and I see consistent behaviour. Perhaps I'm looking at the wrong functions? Can you post an example / test in which this happens?

@maurolacy
Copy link
Collaborator

maurolacy commented Jul 15, 2023

Will work on making the queries return Locked for locked items instead of errors. That will standardise all the queries.

Those are:

  • vault::account_claims
  • external_staking::stake
  • external_staking::stakes

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 a pull request may close this issue.

2 participants