Highlights of what’s new in 0.7.1
The 0.7.1 release includes new features and fixes to DFX commands, Motoko, the Motoko base library, and Candid.
New features and capabilities
The most significant new features and capabilities include the following updates for DFX commands:
An update to the
dfx canister signcommand enables you to sign
request_statusmessages for update calls.
If you are using
dfx canister signto call a method that generates an update message, the command also signs a corresponding
request_statusmessage and appends it to the
signed_request_status. After you send the message using the
dfx canister sendcommand, you can check the
request_statusof the call by running the following command:
dfx canister send message.json --status
This change is particularly useful if you are using the
dfx canister signand
dfx canister sendcommands to call the
governancecanister to make a transaction or stake tokens as a two-step process.
There are new
uninstall_codemanagement canister methods that are also exposed as
The two new commands are
dfx canister deposit-cyclesand
dfx canister uninstall-code. For example, you can now send cycles from your cycles wallet to a specific canister by running a command similar to the following:
dfx canister deposit-cycles 125000000000 hello_world
You can uninstall code for a deployed WASM module by running a command similar to the following:
dfx canister uninstall-code hello_world
--no-artificial-delayoption enables you to reduce the time it takes for the local Internet Computer to start.
This change adds the
dfx replicacommands. By default, the local Internet Computer replica that is installed with the SDK has an artificial consensus delay to simulate the delay users might see in a networked environment. With this new flag, you can skip the built-in delay when you start the local Internet Computer by running either the
dfx start --no-artificial-delayor
dfx replica --no-artificial-delaycommand.
For example, you can start the local Internet Computer without a delay by running the following command:
dfx start -no-artificial-delay
If you use this option, however, you might an increase in the CPU used by the local Internet Computer replica.
The SDK version 0.7.1 introduces a change to the default principal used when you run
dfx canister call commands. Depending on the version of the SDK that you were previously using, this change might require changes to your program code or to the way you call methods in deployed canisters.
The cycles wallet canister identifier is not longer used as the message caller by default.
In some previous versions of the SDK, the
dfx canister callcommand would use the cycles wallet canister identifier as the message caller to perform queries and update calls by default.
--no-walletcommand-line option was introduced to allow you to bypass the cycles wallet canister identifier and perform query and update calls using the currently-selected identity.
However, using the cycles wallet canister identifier to execute
dfx canister callcommands resulted in each call being treated as an inter-canister call and the calls would take longer than necessary to resolve.
With this release,
dfx canister callcommands no longer use the cycles wallet canister identifier to execute query and update calls by default. If you want to execute a query or update call using the cycles wallet, you can run a command similar to the following:
dfx canister --wallet=cycles-wallet-id call canister method
Issues fixed in this release
This section covers any reported issues that have been fixed in this release.
Allow consistent use of canisters names or identifiers in
dfx canistercommands were inconsistent about whether you could specify a canister using a canister name or a canister identifier. With this change, all
dfx canistercommands now accept either a canister name as specified in the local
dfx.jsonconfiguration file or a valid canister identifier as listed in the