You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our handle_contracts logic currently assumes that it is being run for the first time. Right now, it will:
run contract install --wasm path/to/some.wasm to get the current wasm binary on-chain
run contract deploy --wasm-hash [return value of step 1] to create a new contract using this hash
run contract bindings typescript for this newly-created contract
overwrite the src/contracts/[contract name].ts file with the new contract ID from step 2
Instead, it should:
run contract install --wasm path/to/some.wasm to get the current wasm binary on-chain. Yes, this is the same first step. This operation is idempotent, meaning it will always return the same hash for the same wasm blob.
check if we have an alias saved for this contract (this depends on the recenly-added alias logic)
if no alias, proceed as we currently do, but save the alias on the contract deploy step so we can use it next time
if we have an alias, check if the contract with that ID is using the wasm hash generated in step 1. if so, then we're done.
if we need to update the contract with the new code, we have a decision to make. Do we deploy a new contract, for simplicity? Maybe for now, assuming that we'll be using this in local & other test networks, that's the most straightforward option. And maybe for production environments and/or live networks, we throw an error for now. Because what really should happen is that we update the contract with the new code and make sure we run any relevant migrations and, and, and...
We should probably integrate with smartdeploy to help us handle this more complicated update strategy?
The text was updated successfully, but these errors were encountered:
Follow-up to #42
Our handle_contracts logic currently assumes that it is being run for the first time. Right now, it will:
contract install --wasm path/to/some.wasm
to get the current wasm binary on-chaincontract deploy --wasm-hash [return value of step 1]
to create a new contract using this hashcontract bindings typescript
for this newly-created contractsrc/contracts/[contract name].ts
file with the new contract ID from step 2Instead, it should:
run
contract install --wasm path/to/some.wasm
to get the current wasm binary on-chain. Yes, this is the same first step. This operation is idempotent, meaning it will always return the same hash for the same wasm blob.check if we have an
alias
saved for this contract (this depends on the recenly-added alias logic)if no alias, proceed as we currently do, but save the alias on the
contract deploy
step so we can use it next timeif we have an alias, check if the contract with that ID is using the wasm hash generated in step 1. if so, then we're done.
if we need to update the contract with the new code, we have a decision to make. Do we deploy a new contract, for simplicity? Maybe for now, assuming that we'll be using this in local & other test networks, that's the most straightforward option. And maybe for
production
environments and/or live networks, we throw an error for now. Because what really should happen is that we update the contract with the new code and make sure we run any relevant migrations and, and, and...We should probably integrate with smartdeploy to help us handle this more complicated update strategy?
The text was updated successfully, but these errors were encountered: