Skip to main content

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 sign command enables you to sign request_status messages for update calls.

    If you are using dfx canister sign to call a method that generates an update message, the command also signs a corresponding request_status message and appends it to the message.json file as signed_request_status. After you send the message using the dfx canister send command, you can check the request_status of 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 sign and dfx canister send commands to call the ledger or governance canister to make a transaction or stake tokens as a two-step process.

  • There are new deposit_cycles and uninstall_code management canister methods that are also exposed as dfx canister subcommands.

    The two new commands are dfx canister deposit-cycles and 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

  • A new --no-artificial-delay option enables you to reduce the time it takes for the local Internet Computer to start.

    This change adds the --no-artificial-delay flag to dfx start and dfx replica commands. 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-delay or dfx replica --no-artificial-delay command.

    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 observe an increase in the CPU used by the local Internet Computer replica.

Breaking change​

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 no longer used as the message caller by default.

    In some previous versions of the SDK, the dfx canister call command would use the cycles wallet canister identifier as the message caller to perform queries and update calls by default.

    The --no-wallet command-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 call commands 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 call commands 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 canister commands.

    Previously, dfx canister commands were inconsistent about whether you could specify a canister using a canister name or a canister identifier. With this change, all dfx canister commands now accept either a canister name as specified in the local dfx.json configuration file or a valid canister identifier as listed in the canister_ids.json file.