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

mock_env() returns a contract address that cannot be validated #2211

Closed
Tracked by #2157
webmaster128 opened this issue Aug 13, 2024 · 4 comments
Closed
Tracked by #2157

mock_env() returns a contract address that cannot be validated #2211

webmaster128 opened this issue Aug 13, 2024 · 4 comments
Milestone

Comments

@webmaster128
Copy link
Member

webmaster128 commented Aug 13, 2024

(https://github.com/CosmWasm/cosmwasm/blob/v2.0.3/packages/std/src/testing/mock.rs#L282). I.e. the address of the contract itself cannot be canonicalized.


I wonder if we should add a mock_env method to MockApi or use a free function with an api argument

@webmaster128 webmaster128 changed the title mock_env() returns a contract address that cannot be validated (https://github.com/CosmWasm/cosmwasm/blob/v2.0.3/packages/std/src/testing/mock.rs#L282). I.e. the address of the contract itself cannot be canonicalized. mock_env() returns a contract address that cannot be validated Aug 13, 2024
@webmaster128 webmaster128 added this to the 2.2.0 milestone Aug 13, 2024
@webmaster128
Copy link
Member Author

With #2217 being merged now (mock_env changed to use default bech32 address instead of deprecated), @chipshort do you think we should continue this advanced approach as well? It can either be

  • a free function that takes an API argument
  • MockApi::mock_env
  • a free function that takes the final Addr

Alternatively we can leave it up to the project to come up with their Env constructor.

@chipshort
Copy link
Collaborator

I think we could keep it in the backlog for a 3.0, where we can then make breaking changes to the existing functions, but I would not do it now. It feels quite awkward to have multiple versions of the mocking function doing almost the same thing, but not quite. And the naming is not very obvious either.
So, better to stay with the 80/20 solution for now and whoever needs custom prefixes can implement it themselves.
Then, in 3.0 we can switch over to the full solution.

@webmaster128
Copy link
Member Author

Good call, I like! Added to milestone

@chipshort chipshort modified the milestones: 2.2.0, 3.0.0 Aug 21, 2024
@webmaster128
Copy link
Member Author

Closing in favour of #2218. I consider this task 80% done in #2217

@webmaster128 webmaster128 modified the milestones: 3.0.0, 2.2.0 Aug 21, 2024
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

No branches or pull requests

2 participants