-
Notifications
You must be signed in to change notification settings - Fork 355
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
implement demo cw1155 contract #251
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.
I just got back from vacation and have lots to do before I can take a deeper look, but I did add comments on the 2 FIXMEs. These are subtle points about how cosmwasm-std
is designed and actually intended.
} | ||
} | ||
|
||
fn checked_add(a: Uint128, b: Uint128) -> StdResult<Uint128> { |
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.
Interesting. We define sub
for Uint128
to possibly return an error if it underflows (not enough balance). We don't do this for adding as we assumed this would never happen.
We do however, test that this extremely rare condition causes a panic, which is enough to keep the contract secure. It won't provide a pretty error message to the user, but will block the attack vector. I would just use the normal Uint128 + Uint128
approach
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.
I reverted back to simple +
operator.
Opened issue in cosmwasm-std for the overflow handling: CosmWasm/cosmwasm#850
.unwrap(); | ||
} | ||
|
||
// // FIXME test failed, query result out of order |
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.
They are not "out of order", it is that the keys are stored in CanonicalAddr
, which you cannot assume is the same ordering as HumanAddr
. For bech32 the order sometimes is the same, sometimes different. For tests, we semi-randomize the mapping to ensure you do not depend on it.
If you hardcode some addresses, just figure out via a few test runs what the ordering is as CanonicalAddr and then assert that one. It will be stable, but it makes you be sure if you are comparing canonical or human addresses.
Discussion here: CosmWasm/cosmwasm#552
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.
thanks for clarification, FIXME is resolved now.
Thanks, two FIXMEs are resolved now. |
a1b7cb0
to
72ea5e8
Compare
Added unit tests to expect panic when minting token amount overflow. |
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 work. And sorry for the delay in reviewing, between vacation and Easter and end-of-the-month, my work weeks have been full.
I made some stylistic comments on a few places, but quite impressed with the quality of the code. And I learned a few techniques I'd like to emulate for other contracts. Especially the event system and inlining those query functions.
If you want to take a pass and address some of the minor comments, I am happy to merge it. Very nice addition to cosmwasm-plus
.unwrap(), | ||
Response { | ||
attributes: vec![ | ||
attr("action", "transfer"), |
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.
This is interesting. I am not sure how this ends up when it comes out through tendermint (I think it does some "collapsing" of events).
It totally makes sense. I wonder if you had a wish on a cleaner way to encode these or pass them through to the client? Although I guess just as it is is perfect for searching.
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.
I'm not sure how it's going to be indexed by tendermint though, need to look into details in tendermint I guess.
EDIT:
Yeah, i guess it would be fine, since tendermint will index attributes independently?
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.
Yeah, they should all match
test approval expires
- Use entry_point macro - bump dependencies to alpha3 - Remove unused struct - Remove guard helper - Other misc changes
rsp.messages = if let Some(msg) = msg { | ||
vec![Cw1155ReceiveMsg { | ||
if let Some(msg) = msg { | ||
rsp.messages = vec![Cw1155ReceiveMsg { |
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.
This could also be rsp.add_message(Cw1155ReceiveMsg { .. }.into_cosmos_msg(to)?);
But I don't think that is any clearer in this case.
// insert if not exist | ||
let key = TOKENS.key(&token_id); | ||
if deps.storage.get(&key).is_none() { | ||
// insert an empty entry so token enumeration can find it |
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.
thanks for the comment
@@ -42,6 +44,7 @@ pub struct ExecuteEnv<'a> { | |||
info: MessageInfo, | |||
} | |||
|
|||
#[cfg_attr(not(feature = "library"), entry_point)] |
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 update
if !check_can_approve(deps.as_ref(), &env, &from, &info.sender)? { | ||
return Err(ContractError::Unauthorized {}); | ||
} | ||
guard_can_approve(deps.as_ref(), &env, &from, &info.sender)?; |
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.
Yeah, this is a nicer way to inline the common check.
.unwrap(), | ||
Response { | ||
attributes: vec![ | ||
attr("action", "transfer"), |
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.
Yeah, they should all match
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.
Good stuff.
Created #261 inspired by your comments |
there are several more unit tests to be done, the overall implementation is good for review now.
There are two
FIXME
currently:StdError
.