-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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 storage deposit support in apps #6657
Add storage deposit support in apps #6657
Conversation
The above one is problematic - the RPC results changed. The API have a |
isZeroable={hasStorageDeposit} | ||
isZeroable={contractAbi.constructors[constructorIndex].isPayable} |
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.
What does isZeroable
do if true? Asking because zero could still be a valid value when the constructor/message is payable.
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.
if it's true then 0 can be an acceptable value, otherwise the input validation fails. the input gets a red border and you can't move to the next step
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.
now i tried with the older node and even if the constructor is not payable, the transaction fails with "contract not founded" if i pass 0.
is is safe to assume that if the node supports storage deposit than the value can be 0 for non payable constructors?
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.
You have to differentiate between ABI (payable) and the node. ABI comes from ink! and is decoupled from the node version.
Old Node:
Always needs value/endowment
in order to pay for rent. Disregard payable
.
New Node:
Does not need any value
except if the constructor is payable
. Hence you should not even show the field and use 0
when the constructor isn't payable.
ink!:
Ink constructors are implicitly payable. The fuck up is that this is implicit. The field is missing from ABI. What you should do is interpete the absense of the payable field as payable = true
. We intent to make it explicit and also allow to make them not payable. The following is forward compatible:
undefined
-> true
false
-> false
true
-> true
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.
ok, got it!
i am using this api.tx.contracts.instantiate.meta.args.length === 6
to check if the node has storage deposit or not. because the changes to value are related to storage deposit i wanted to double check it the same condition can be used
@jacogr this is ready for review, i think. is there something else we can do to get this available to the users faster? |
I'll get through the queue - I know I'm a bottlenck, it takes a while to get to stuff in the review queue. (In apps I currently have a large number of PRs > 1 month old which has not had a look, the queue should be at 0 and it runs longer than a page here, just because of not getting there. It has been quite neglected due to pressures elsewhere.) |
whenever you have some time. build should pass now. |
On the list for today. |
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.
lgtm code-wise, just some small comments.
The bumps here are weird, was it done manually?
@@ -50,6 +51,7 @@ function Deploy ({ codeHash, constructorIndex = 0, onClose, setConstructorIndex | |||
|
|||
const [name, isNameValid, setName] = useNonEmptyString(code && code.json.name); | |||
const { contractAbi, errorText, isAbiError, isAbiSupplied, isAbiValid, onChangeAbi, onRemoveAbi } = useAbi([code && code.json.abi, code && code.contractAbi], codeHash, true); | |||
const isConstructorPayable = contractAbi?.constructors[constructorIndex].isPayable !== false; |
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 would always be true. It does not get set on constructors at this point at all. So it will be undefined !== false
in all cases.
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.
the intention is to make the constructors explicitly payable / not payable in ink!
just trying to be forward compatible. but yes, it's an unnecessary check at this 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.
I understand that, but it is actually not forward-compatible at all :) Until we have a plan for the actual ABI definitions, so at this point is is guessing... So, if we want to really do this - pass the flag here https://github.com/polkadot-js/api/blob/master/packages/api-contract/src/Abi/index.ts#L93 (like we do for messages)
For now it would need to always be isPayable: true
. When the time comes that the constructors pass it, on the API level it would need to change that field into an Option<bool>
for the decoders. The we need to change the always-true
be a isPayable: o.isNone || o.unwrap().isTrue
(to maintain backwards compat where it was not passed)
So not against the checks, however the tristate logic should not sit quite here. It is ok for now, but needs cleanup on the ABI level and then here.
yarn.lock
Outdated
languageName: node | ||
linkType: hard | ||
|
||
"@polkadot/api-contract@npm:^7.0.3-0": |
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.
Somewhere things got mismatched between the versions here - the ./dev/all-update.sh
script will ensure there is a single version and dedupe it as well. (The lockfile here is weird with the -0
& -1
matching)
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.
what i did is to bump the versions in package.json
and then run yarn
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.
Ahh, yes, that is the issue - they are in multiple places in the root and in the workspace level (not actually enough, most pages do still pull in transient deps).
Just merge in master and we should be good to go :) |
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.
Thank you very much, this is great!
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Introduced in Substrate here
Done: