-
Notifications
You must be signed in to change notification settings - Fork 145
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
Dao voting cw4 cleanup #691
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #691 +/- ##
==========================================
+ Coverage 93.82% 93.94% +0.12%
==========================================
Files 60 60
Lines 5149 5189 +40
==========================================
+ Hits 4831 4875 +44
+ Misses 318 314 -4
☔ View full report in Codecov by Sentry. |
Cosm-Orc Gas Usage
Raw Report for ae9600a
|
} | ||
GroupContract::Existing { address } => { | ||
let group_contract = deps.api.addr_validate(&address)?; |
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.
could something go wrong here if the address is valid but does not point to a valid GroupContract
?
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.
Yes. @0xekez, any ideas for validation here?
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.
Without providing any additional data, I guess you can query ListMembers
with limit: 1, and verify the response is valid format (MemberListResponse { members }
) and not empty?
This will:
- Verify the contract have
ListMembers
query with the right response format - Verify the members list is not empty
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.
Perhaps it would be nice to use a similar pattern as with UncheckedDepositInfo
and CheckedDepositInfo
in dao-voting
module to validate the group contract
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.
Whats the conclusion on this? I think some minimal verification is best to at least try and catch some obvious user errors
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! Just got 1 question
What about admin of existing cw4-group?
When creating new group you set it to be the DAO, maybe this contract should verify that the DAO is the admin or its not set?
} | ||
GroupContract::Existing { address } => { | ||
let group_contract = deps.api.addr_validate(&address)?; |
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.
Without providing any additional data, I guess you can query ListMembers
with limit: 1, and verify the response is valid format (MemberListResponse { members }
) and not empty?
This will:
- Verify the contract have
ListMembers
query with the right response format - Verify the members list is not empty
Good question! IMO this should not be enforced. What about things like SubDAOs where a certain groups contract may be used across multiple SubDAOs? That said, folks should exercise caution when using existing contracts if they don't understand who controls them. Feel this should be more of a UX thing. |
732fb0a
to
4f94ef8
Compare
nightly broke a bunch of linting stuff, we should probably be using stable
pub fn execute( | ||
_deps: DepsMut, | ||
_env: Env, | ||
_info: MessageInfo, | ||
_msg: ExecuteMsg, | ||
) -> Result<Response, ContractError> { | ||
Err(ContractError::NoExecute {}) |
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.
Complains no tests, I guess you can just add a simple test that trying to execute something errors?
should be a good reminder in the future to add test if execute msgs are added as well
} | ||
GroupContract::Existing { address } => { | ||
let group_contract = deps.api.addr_validate(&address)?; |
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.
Whats the conclusion on this? I think some minimal verification is best to at least try and catch some obvious user errors
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.
untested ACK: lgtm.
just 2 things came up:
- note: I attempted to compile and test; however, I ran in to this error. It may be an environment issue on my machine, but I wanted to bring it up anyways:
error[E0658]: `let...else` statements are unstable
--> /Users/whiskey/.cargo/registry/src/github.com-1ecc6299db9ec823/cw-ownable-derive-0.5.1/src/lib.rs:22:5
- thought: there's a test case that checks total vp at height (
test_power_at_height
) and it does modification of VP (see line 284 of tests.rs. If these are possible scenarios, I'd actually like to see another test that instantiates a dao with disproportionate vp -- asetup_test_case
with VP's of 1, 1, 2, 0
* Refactor cw4 voting * Fix up tests and bugs * Add test for using an existing group contract * Update schema * Fix clippy * nightly -> stable for CI nightly broke a bunch of linting stuff, we should probably be using stable
Closes #675