dfinity / sdk Goto Github PK

IC SDK: a Software Development Kit for creating and managing canister smart contracts on the ICP blockchain.

Home Page: https://internetcomputer.org/developers

License: Apache License 2.0

Rust 71.69% JavaScript 0.51% Shell 23.68% Modelica 0.01% Python 0.67% HTML 0.07% Motoko 2.92% Dockerfile 0.16% Handlebars 0.13% TypeScript 0.01% SCSS 0.09% Svelte 0.03% Vue 0.03%

blockchain canister internet-computer rust sdk smart-contract icp dfx

sdk's Introduction

IC SDK

This repo contains the IC SDK: a Software Development Kit for creating and managing canister smart contracts on the Internet Computer (ICP blockchain).

For further reading:

What gets installed

The IC SDK installation script installs several components in default locations on your local computer. The following table describes the development environment components that the installation script installs:

Component	Description	Default location
dfx	Command-line interface (CLI)	`/usr/local/bin/dfx`
moc	Motoko runtime compiler	`~/.cache/dfinity/versions/<VERSION>/moc`
replica	Internet Computer local network binary	`~/.cache/dfinity/versions/<VERSION>/replica`
uninstall.sh	Script to remove the SDK and all of its components	`~/.cache/dfinity/uninstall.sh`
versions	Cache directory that contains a subdirectory for each version of the SDK you install.	`~/.cache/dfinity/versions`

SDK vs CDK vs `dfx`

There are a few components above worth expanding on:

dfx - dfx is the command-line interface for the IC SDK. This is why many commands for the IC SDK start with the command "dfx .." such as dfx new or dfx stop.
Canister Development Kit (CDK) - A CDK is an adapter used by the IC SDK so a programming language has the features needed to create and manage canisters. The IC SDK comes with a few CDKs already installed for you so you can use them in the language of yoru choice. That is why there is a Rust CDK, Python CDK, TypeScript CDK, etc... Since CDKs are components used the SDK, some developer choose to use the CDK directly (without the IC SDK), but typically are used as part of the whole IC SDK.

Getting Started

Installing

You can install the IC SDK a few different ways.

via `curl` (recommended)

sh -ci "$(curl -fsSL https://internetcomputer.org/install.sh)"

This command will install a binary compatible with your operating system, and add it to /usr/local/bin.

via GitHub Releases

Find a release for your architecture here.

in GitHub Action, using `dfinity/setup-dfx`

    steps:
    - name: Install dfx
      uses: dfinity/setup-dfx@main

Getting Help

Once the IC SDK is installed, get acquainted with its capabilities by entering.

dfx help

Contributing to the DFINITY SDK

See our contributing guidelines here.

Building the IC SDK

Building the IC SDK is very simple:

cargo build

Release Process

IC SDK is released in two steps:

Publishing a new IC SDK release.
Publishing a new manifest.json and install.sh to instruct the installer to actually download and install the new IC SDK release.

Publishing the IC SDK

The release manager makes sure the dfx stable branch points to the revision that should be released and that the revision is tagged with a version (like 0.5.6).
The sdk-release jobset on Hydra tracks the stable branch and starts evaluating shortly after stable advances.
As you can see it only has the single job publish.dfx which is defined here in terms of the dfx job. Note that the publish.dfx job only exists when the revision has a proper version tag. This prevents publishing of untagged revisions.
Our CD system running at deployer.dfinity.systems is configured with the publish-sdk-dfx-release job. It will monitor the aforementioned publish.dfx job for new builds, whenever there's a new build it will download the output (the CD script) and execute it.
As you can see the script also sends a message to the #build-notifications Slack channel so you can see when and if the SDK has been published.

Publishing `manifest.json` and `install.sh`

After the IC SDK has been released it's available for download but the install script at https://sdk.dfinity.org/install.sh won't immediately install it. To make sure the installer actually downloads and installs the new IC SDK release the manifest.json file at https://sdk.dfinity.org/manifest.json has to set its tags.latest field to the new version. The following explains how to do that.

Edit the public/manifest.json file such that it points to the new IC SDK version and make sure this is merged in master.
Similarly to releasing the IC SDK there's a install-sh job that builds a CD script for publishing the manifest.json and install.sh to our CDN.
This job is built on the sdk jobset which tracks the master branch.
deployer.dfinity.systems is configured with the publish-sdk-install-sh job which will monitor the aforementioned publish.install-sh.x86_64-linux job for new builds, whenever there's a new build it will download the output (the CD script) and execute it.

Troubleshooting

This section provides solutions to problems you might encounter when using the IC SDK via dfx command line

Project Reset

This command will remove the build directory and restart your replica:

dfx stop && dfx start --clean --background

Using Internet Identity Locally

You can deploy the Internet Identity canister into your replica alongside your project by cloning https://github.com/dfinity/internet-identity. From the internet-identity directory, run the following command:

II_ENV=development dfx deploy --no-wallet --argument '(null)'

There are more notes at https://github.com/dfinity/internet-identity#running-locally that may be helpful.

sdk's People

Contributors

Stargazers

Watchers

Forkers

nomeata c-b-elite a-sklyarov donmreyes umgefahren ethereumspace icp-foundation 4c656554 classicvalues pipe-tools testdrive64 bioerrorlog jzxchiang1 rikonor icpbox gajendraks shashankh-j cfwhisperer paulyoung pipe-ref msgpo 3cl1p5e7 danielhatoshi domwoe xerxes155 japan-dfinityinfohub mrwoo034 andnasnd miguel-title zhenghaooo fantasyjays bxswssmbdx honopu ozwaldorf nmattia saikatdas0790 devidw ericswanson-dfinity bitfinity-network sathishvjd minkj1992 oggy-dfin rahulksnv ninegua levifeldman johnson999666 patrickishaf leonlabsldn v2i0s2h2 vinayakkalra mmicu keplervital dfinity-berestovskyy vporton web3nl ubinix-warun miguelgargallo masterang007 hpeebles novatechspace22 q2333gh 3scava1i3r 0xgoerlimainnet ahdrahees devilogin zhaobing2006 mita23456 tevin-isaac vincent-dfinity maksymar mainangaruiya filippofinke burhansyah 0xmmbd hackartists krpeacock sadernalwis byalexandar linnefromice 0xjoichiro olaszakos

sdk's Issues

A controller can authorize another principal to install code for a canister

This language is changing rapidly but I think these are the current words we're using.

DFX should report its version based on what is installed, not dfx.json

We have some work for this, but not enough. There should be a dfx version that shows version installed, defined in the project, and latest in the cache.

References to "Client" should be "Replica" when starting dfx

Output:

Alexas-MacBook-Pro:actor_hello alexasmith$ dfx start
⠁ Starting up the client...
Mar 05 18:09:05.891 INFO Dfinity Replica Started
Mar 05 18:09:05.915 INFO Generated node ID: 10205374693260198624
Mar 05 18:09:05.920 INFO Using path '/Users/alexasmith/ic-projects/actor_hello/.dfx/state' to manage local state, StateManager: 1
Mar 05 18:09:05.922 INFO ConnManager: node_id = 10205374693260198624, node_ip = "127.0.0.1", Application: TransportConnectionMgr
Mar 05 18:09:05.922 INFO ConnManager::init_client(): client_type = P2P, Applicat⠤ Client bound at 49618
client address: "http://localhost:49618"
binding to: V4(127.0.0.1:8000)
Internet Computer client started...

Fixed for dfx replica but not dfx start

Point e2e tests at latest approved version of ic-ref instead of "legacy"

Run E2E tests in headless browsers

Basically Firefox and Chrome headless.

Install the dfx version that is being used if it isn't available

If the dfx version specified (either through dfx.json or env variable or otherwise) isn't in the cache, we should download it as if we were upgrading.

Run `dfx build` on the examples repo as part of our CI

Refactor Replica to an actor model

Add support for WAT -> WASM compilation

Which most likely include some scheme to get the IDL from somewhere.

A developer should be able to run tests with `dfx test`

I’m removing myself as the assignee from this ticket.

IIRC, Hans Larsen asked me to write a design document for dfx test, which I did last week, as a PR to the sdk repo, per his request ( #354 ). I believe that implementing some design for dfx test is beyond the scope of his original request.

Started work in #354

A developer can interact with their canister in a REPL

From the JIRA ticket:

Things to consider:

simple syntax or full Motoko repl?
IDL resolution to know if a call is a query or an update
utility functions?
debugging features?

Comments from @chenyan-dfinity:

I would prefer we narrow the scope to just define the interface for calling/querying canisters, not going for REPL. Note that in this REPL, the only thing you can do is to make function calls to canisters. There is no notion of environment, no stateful computation. Everything can be done as a one-liner in CLI command.

For 2, IDL already supports this, e.g.

service s {
  f: (nat) -> (nat) query;
  g: (nat) -> (nat);
}

f is a query function and g is an update.
Definitely no for 1,3,4. I think we are conflating two different concepts here: CLI and the Motoko language.

Motoko already has REPL, stdlib and debugging support. It’s fair to ask for more features, but I don’t see any features that are not possible at the language level, and requires CLI support.

CLI should be language neutral. We are going to support Rust soon. Making a repl or query syntax similar to Motoko is not friendly to Rust developers. That’s exactly why we design the IDL syntax to be different from Motoko.

To be language neutral, CLI should only understand IDL, and treat Motoko and Rust as blackbox. The only thing IDL allows is to send/recv messages. Having a REPL is not going to buy us more features. We can of course send different messages to the canister to debug for decoding, encoding, and subtyping, but that’s all handled in IDL, and CLI should not worry about these things neither.

BigInt function error

Populating and array this way with m and n > 10000000

import Array "mo:stdlib/array"
actor Example {
  public func example(n : Nat, m : Nat) {
    let _ = Array.init<Bool>(n * m, false);
  }
}

leads to the following error:
Client error (code 5): IC0503: Canister ic:9E70563D976354BCD8 trapped explicitly: bigint function error

Here's the related forum post:
https://forum.dfinity.org/t/bigint-function-error/526

A developer can manage third-party libraries

To consider:

A Motoko Package Manager: Can pull in packages written in Motoko to be imported by your app, which is also written in Motoko. You could then compile your app into WebAssembly and install it as a canister. This approach makes Motoko a first class language like Node or Rust.

An Internet Computer Package Manager: Can pull in WebAssembly modules written in ANY language to be linked by your app, also written in ANY language and compiled to WebAssembly. This approach make Motoko less important but creates a flourishing ecosystem around developing for the Internet Computer itself.

A Canister Package Manager: Can pull in references to IC Canisters running on the Internet Computer. Developers could create a canister, deploy it, and allow it to be called by other canisters for payment. This approach gives Open Source software developers a business model based in how useful their software is, potentially changing the face of tech as we know it.

Some of these strategies should live in SDK, others with the Languages team.

Run E2E tests in target browsers

This is blocked on #471 because we will want to run the same tests.

Error message for dfx start --clean

dfx version: 0.5.4
OS: Ubuntu 18.04

Running "dfx start --clean" on a brand new project throws the following error, it may be useful to let the user know that there is no state to clean yet.

An error occured:
CleanState(
Os {
code: 2,
kind: NotFound,
message: "No such file or directory",
},
)

Stack overflow bug with http handler

Reported from the community:

When running this minimal actor with n > 39

actor Test {
    public query func example(n : Nat) : async Text{
        var output : Text = "\n";
        var current_row: Nat = 0;

        for (index in Iter.range(0,n*n-1)){
            
            if (index/n > current_row){
                output #= "\n";
                current_row += 1;
            };

            output #= "◼";

        };

        return output;
    };
};

It will fail with the following error:

Mar 21 17:31:31.284 WARN Could not perform query on canister: IC0502: Canister ic:9888BAFBFF1508D5AC trapped: stack overflow, Application: Http Handler

Somehow it seems like a Text can’t contain more than 1634 characters?

Update bootstrap to support default canisters or list canisters available

If the canisterId isn't specified, AND we're running locally, we should connect to an internal webserver API that gives us a list of canisters available. That way we can tell the user which one they have installed and use them.

This depends on some GraphQL API to talk to the server.

Allow for verification of checksum during SDK installation

This would include:

Show the user a checksum of the file downloaded so they can validate it
Allow the user to approve/deny downloads based on their checksum

Probably want to keep the default flow as seamless as it is now.

Files in the cache lack proper creation date and time

Previous conversation:

Dates should be the date they were built. I think js-user-library and stdlib are correct, since we use mkdir in Nix to create those, but files aren’t because build outputs in Nix are set to EPOCH.

ok so we will need to change the date after they are build but prior to us bundling them (if it is during, we still do that in nix, so the date should be 0 I think?!)

I’m pretty sure if we do that in build.rs prior to bundling it fixes it.

A developer can select a dummy user identity for request signing

If a developer is working on a front-end application, it would be nice if they could quickly swap between dummy identities to test access (for example).

The original description:

The standard UserLib should contain several dummy user identities that can be selected from the front-end application for the purposes of signing user requests to the canister. These identities are likely key pairs with minimal metadata (like IDs and maybe human-readable names as an affordance) that can be switched between in the browser developer tools console (i.e. window.DFINITY.switchUsers(1);). We may consider enhancing this behavior with a browser extension in the future.

Moc compiler mo-rts.wasm location

Support ticket from Zendesk:

I'm not sure if the standalone moc compiler is supported yet, but I get this error when running with a file as input: "..../.cache/dfinity/versions/0.5.2/../rts/mo-rts.wasm: No such file or directory"

"mo-rts.wasm" is currently in versions/0.5.2/ . Manually moving it to versions/rts/ solves this.

If you are using the standalone moc compiler, you need to set the MOC_RTS environment variable to pointing to the mo-rts.wasmfile. The default location is “the location of the mocbinary/../rts/mo-rts.wasm”.

I think that’s a bug not a feature. It should look in the same folder by default.

Reopen this as the fix seems to be easier from SDK side.

One way to fix this is to add some structure to .cache directory: put all binaries in bin/, and runtime in rts/. Then the default behavior will work fine. WDYT?

A developer can receive an error when trying to install a canister incompatible with that version of replica

Replica subcommand is not configurable via dfx.json

A developer can query the status of a running network

The Replica now supports a status endpoint. The CLI should as well.

Test Issue

Build a series of e2e tests for our example repos

The tests should probably be in some kind of scripting (bash but not bats?) and be run with the SDK CI on new PRs.

A developer can validate update call results are signed

Once an update call is executed, the developer can currently request its status and get a result but without it being signed by the sub-network (or some other entity) there's no guarantee the node isn't lying.

A developer can inspect a running canister to receive its Candid file

HTTP Agent Test race

18:54:11] test agent::agent_test::query_rejected ... ok
[2020-02-17 18:54:11]
[2020-02-17 18:54:11] failures:
[2020-02-17 18:54:11]
[2020-02-17 18:54:11] ---- agent::agent_test::call stdout ----
[2020-02-17 18:54:11] thread 'agent::agent_test::call' panicked at 'assertion failed: `(left == right)`
[2020-02-17 18:54:11]   left: `1`,
[2020-02-17 18:54:11]  right: `0`:
[2020-02-17 18:54:11] > Expected 1 request(s) to:
[2020-02-17 18:54:11]
[2020-02-17 18:54:11] POST /api/v1/read?(any)
[2020-02-17 18:54:11]
[2020-02-17 18:54:11] ...but received 0
[2020-02-17 18:54:11]
[2020-02-17 18:54:11] ', /nix/store/w5vhayfhbknllxd14rnba6r7lww6x8bb-crates-io/mockito-0.20.0/src/lib.rs:928:44
[2020-02-17 18:54:11] stack backtrace:
[2020-02-17 18:54:11]    0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
[2020-02-17 18:54:11]    1: core::fmt::write
[2020-02-17 18:54:11]    2: std::io::Write::write_fmt
[2020-02-17 18:54:11]    3: std::io::impls::<impl std::io::Write for alloc::boxed::Box<W>>::write_fmt
[2020-02-17 18:54:11]    4: std::panicking::default_hook::{{closure}}
[2020-02-17 18:54:11]    5: std::panicking::default_hook
[2020-02-17 18:54:11]    6: std::panicking::rust_panic_with_hook
[2020-02-17 18:54:11]    7: std::panicking::continue_panic_fmt
[2020-02-17 18:54:11]    8: std::panicking::begin_panic_fmt
[2020-02-17 18:54:11]    9: mockito::Mock::assert
[2020-02-17 18:54:11]   10: ic_http_agent::agent::agent_test::call
[2020-02-17 18:54:11]   11: core::ops::function::FnOnce::call_once
[2020-02-17 18:54:11]   12: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
[2020-02-17 18:54:11]   13: __rust_maybe_catch_panic
[2020-02-17 18:54:11]   14: test::run_test_in_process
[2020-02-17 18:54:11] note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
[2020-02-17 18:54:11]
[2020-02-17 18:54:11] ---- agent::agent_test::call_rejected stdout ----
[2020-02-17 18:54:11] thread 'agent::agent_test::call_rejected' panicked at 'assertion failed: `(left == right)`
[2020-02-17 18:54:11]   left: `1`,
[2020-02-17 18:54:11]  right: `0`:
[2020-02-17 18:54:11] > Expected 1 request(s) to:
[2020-02-17 18:54:11]
[2020-02-17 18:54:11] POST /api/v1/read?(any)
[2020-02-17 18:54:11]
[2020-02-17 18:54:11] ...but received 0
[2020-02-17 18:54:11]
[2020-02-17 18:54:11] ', /nix/store/w5vhayfhbknllxd14rnba6r7lww6x8bb-crates-io/mockito-0.20.0/src/lib.rs:928:44
[2020-02-17 18:54:11] stack backtrace:
[2020-02-17 18:54:11]    0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
[2020-02-17 18:54:11]    1: core::fmt::write
[2020-02-17 18:54:11]    2: std::io::Write::write_fmt
[2020-02-17 18:54:11]    3: std::io::impls::<impl std::io::Write for alloc::boxed::Box<W>>::write_fmt
[2020-02-17 18:54:11]    4: std::panicking::default_hook::{{closure}}
[2020-02-17 18:54:11]    5: std::panicking::default_hook
[2020-02-17 18:54:11]    6: std::panicking::rust_panic_with_hook
[2020-02-17 18:54:11]    7: std::panicking::continue_panic_fmt
[2020-02-17 18:54:11]    8: std::panicking::begin_panic_fmt
[2020-02-17 18:54:11]    9: mockito::Mock::assert
[2020-02-17 18:54:11]   10: ic_http_agent::agent::agent_test::call_rejected
[2020-02-17 18:54:11]   11: core::ops::function::FnOnce::call_once
[2020-02-17 18:54:11]   12: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
[2020-02-17 18:54:11]   13: __rust_maybe_catch_panic
[2020-02-17 18:54:11]   14: test::run_test_in_process
[2020-02-17 18:54:11] note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
[2020-02-17 18:54:11]
[2020-02-17 18:54:11] ---- agent::agent_test::ping_error stdout ----
[2020-02-17 18:54:11] thread 'agent::agent_test::ping_error' panicked at 'assertion failed: `(left == right)`
[2020-02-17 18:54:11]   left: `2`,
[2020-02-17 18:54:11]  right: `1`:
[2020-02-17 18:54:11] > Expected 2 request(s) to:
[2020-02-17 18:54:11]
[2020-02-17 18:54:11] GET /api/v1/read?(any)
[2020-02-17 18:54:11]
[2020-02-17 18:54:11] ...but received 1
[2020-02-17 18:54:11]
[2020-02-17 18:54:11] ', /nix/store/w5vhayfhbknllxd14rnba6r7lww6x8bb-crates-io/mockito-0.20.0/src/lib.rs:928:44
[2020-02-17 18:54:11] stack backtrace:
[2020-02-17 18:54:11]    0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
[2020-02-17 18:54:11]    1: core::fmt::write
[2020-02-17 18:54:11]    2: std::io::Write::write_fmt
[2020-02-17 18:54:11]    3: std::io::impls::<impl std::io::Write for alloc::boxed::Box<W>>::write_fmt
[2020-02-17 18:54:11]    4: std::panicking::default_hook::{{closure}}
[2020-02-17 18:54:11]    5: std::panicking::default_hook
[2020-02-17 18:54:11]    6: std::panicking::rust_panic_with_hook
[2020-02-17 18:54:11]    7: std::panicking::continue_panic_fmt
[2020-02-17 18:54:11]    8: std::panicking::begin_panic_fmt
[2020-02-17 18:54:11]    9: mockito::Mock::assert
[2020-02-17 18:54:11]   10: ic_http_agent::agent::agent_test::ping_error
[2020-02-17 18:54:11]   11: core::ops::function::FnOnce::call_once
[2020-02-17 18:54:11]   12: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
[2020-02-17 18:54:11]   13: __rust_maybe_catch_panic
[2020-02-17 18:54:11]   14: test::run_test_in_process
[2020-02-17 18:54:11] note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
[2020-02-17 18:54:11]
[2020-02-17 18:54:11] ---- agent::agent_test::install stdout ----
[2020-02-17 18:54:11] thread 'agent::agent_test::install' panicked at 'assertion failed: `(left == right)`
[2020-02-17 18:54:11]   left: `1`,
[2020-02-17 18:54:11]  right: `0`:
[2020-02-17 18:54:11] > Expected 1 request(s) to:
[2020-02-17 18:54:11]
[2020-02-17 18:54:11] POST /api/v1/read?(any)
[2020-02-17 18:54:11]
[2020-02-17 18:54:11] ...but received 0
[2020-02-17 18:54:11]
[2020-02-17 18:54:11] ', /nix/store/w5vhayfhbknllxd14rnba6r7lww6x8bb-crates-io/mockito-0.20.0/src/lib.rs:928:44
[2020-02-17 18:54:11] stack backtrace:
[2020-02-17 18:54:11]    0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
[2020-02-17 18:54:11]    1: core::fmt::write
[2020-02-17 18:54:11]    2: std::io::Write::write_fmt
[2020-02-17 18:54:11]    3: std::io::impls::<impl std::io::Write for alloc::boxed::Box<W>>::write_fmt
[2020-02-17 18:54:11]    4: std::panicking::default_hook::{{closure}}
[2020-02-17 18:54:11]    5: std::panicking::default_hook
[2020-02-17 18:54:11]    6: std::panicking::rust_panic_with_hook
[2020-02-17 18:54:11]    7: std::panicking::continue_panic_fmt
[2020-02-17 18:54:11]    8: std::panicking::begin_panic_fmt
[2020-02-17 18:54:11]    9: mockito::Mock::assert
[2020-02-17 18:54:11]   10: ic_http_agent::agent::agent_test::install
[2020-02-17 18:54:11]   11: core::ops::function::FnOnce::call_once
[2020-02-17 18:54:11]   12: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
[2020-02-17 18:54:11]   13: __rust_maybe_catch_panic
[2020-02-17 18:54:11]   14: test::run_test_in_process
[2020-02-17 18:54:11] note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
[2020-02-17 18:54:11]
[2020-02-17 18:54:11]
[2020-02-17 18:54:11] failures:
[2020-02-17 18:54:11]     agent::agent_test::call
[2020-02-17 18:54:11]     agent::agent_test::call_rejected
[2020-02-17 18:54:11]     agent::agent_test::install
[2020-02-17 18:54:11]     agent::agent_test::ping_error
[2020-02-17 18:54:11]
[2020-02-17 18:54:11] test result: FAILED. 11 passed; 4 failed; 0 ignored; 0 measured; 0 filtered out
[2020-02-17 18:54:11]

Unify argument parsing with Clap v3.

A developer can specify a file as an argument for a canister call

Useful for sending a Blob type to test uploading an image for example.

dfx start/upgrade fail on Arch Linux

From Zendesk and Forum:

Hi team,

I was following the “Getting started” guide but neither “dfx start” nor "dfx upgrade " work and both issues seem to be related to SSL certs. Here are the details:

% dfx start
⠁ Starting up the client...
Mar 13 06:51:48.787 INFO Dfinity Replica Started
Mar 13 06:51:48.787 INFO Existing node ID: 6458706763448554563
thread 'main' panicked at 'Could not rename temporary file for port report: Os { code: 18, kind: Other, message: "Invalid cross-device link" }', src/libcore/result.rs:1165:5
⠋ Replica exited with exit code: 101
An error occured:
AgentError(
    TimeoutWaitingForResponse,
)
Strace-ing the dfx start execution I figured out that it tries to load a missing cert file, then it fails:

open("/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-libressl-3.0.2-x86_64-unknown-linux-musl/etc/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such file or directory)
socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_IP) = 10
fcntl(10, F_GETFL)                      = 0x2 (flags O_RDWR)
fcntl(10, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
connect(10, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
epoll_ctl(3, EPOLL_CTL_ADD, 10, {EPOLLIN|EPOLLPRI|EPOLLOUT|EPOLLET, {u32=0, u64=0}}) = 0
epoll_pwait(3, [{EPOLLIN|EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=0, u64=0}}], 1024, -1, NULL, 8) = 1
getsockopt(10, SOL_SOCKET, SO_ERROR, [ECONNREFUSED], [4]) = 0
epoll_ctl(3, EPOLL_CTL_DEL, 10, 0x7ffe066bc928) = 0
close(10)                               = 0
nanosleep({tv_sec=0, tv_nsec=100000000}, Mar 13 06:45:13.731 INFO Dfinity Replica Started
Mar 13 06:45:13.731 INFO Existing node ID: 6458706763448554563
thread 'main' panicked at 'Could not rename temporary file for port report: Os { code: 18, kind: Other, message: "Invalid cross-device link" }', src/libcore/result.rs:1165:5
⠉ Checking client!

I also got the following error while trying the upgrade, somehow it cannot find the SSL certs even if I have both openssl and libressl implementations installed and all certificates are present in /etc/ssl/certs and /etc/libressl/certs

% dfx upgrade
Current version: 0.5.3
Fetching manifest https://sdk.dfinity.org/manifest.json
⠉ Checking for latest dfx version...
An error occured:
Reqwest(
    Error(
        Hyper(
            Error(
                Connect,
                Custom {
                    kind: Other,
                    error: Ssl(
                        Error {
                            code: ErrorCode(
                                1,
                            ),
                            cause: Some(
                                Ssl(
                                    ErrorStack(
                                        [
                                            Error {
                                                code: 335573126,
                                                library: "SSL routines",
                                                function: "CONNECT_CR_CERT",
                                                reason: "certificate verify failed",
                                                file: "/build/libressl-3.0.2/ssl/ssl_clnt.c",
                                                line: 1121,
                                            },
                                        ],
                                    ),
                                ),
                            ),
                        },
                        X509VerifyResult {
                            code: 20,
                            error: "unable to get local issuer certificate",
                        },
                    ),
                },
            ),
        ),
        "https://sdk.dfinity.org/manifest.json",
    ),
)

DFX is a statically linked binary, I looked into it and there is a OPENSSLDIR variable that points to “/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-libressl-3.0.2-x86_64-unknown-linux-musl/etc/ssl” but I could not find a way to overwrite and since I don’t have the dfx source code my debugging stops here.

My system is:
OS: Arch Linux x86_64
Host: 81LF Lenovo Legion Y7000P-1060
Kernel: 5.5.9-arch1-1
Shell: zsh 5.8

A developer can install new code to an existing canister

The CLI can deploy a compiled WebAssembly file to a running network and immediately run all state migrations. The default location of the WebAssembly file(s) to migrate can be added to the config.

$ dfx migrate
[100%] Deploying to local DFINITY network... Done.
[100%] Migrating canister state to latest version (23a7f1bfda0bd578fcf52c5d27c6dd8b85044804)... Done.
 
$ dfx migrate -w ./bin/produce-exchange_1.3.2.wasm
Err: Canister is already running latest version

An end-user can validate update call results are signed

See #480 but for end-users (meaning this is probably in the user library).

Refactor Build to an Actor model

A developer can pass data as part of an installation

The public spec supports an arg argument of type Blob during an install request. We need to support this in the CLI as well.

Support Vessel (package manager)

Add identity proptests

Error with dfx cache start (using V0.5.4)

dfx version: 0.5.3
OS: Ubuntu 18.04

"dfx start" throws the following error:

⠁ Starting up the client...
Mar 14 10:06:42.828 INFO Dfinity Replica Started
Mar 14 10:06:42.829 INFO Existing node ID: 11187036314814542362
thread 'main' panicked at 'Could not rename temporary file for port report: Os { code: 18, kind: Other, message: "Invalid cross-device link" }', src/libcore/result.rs:1165:5
⠋ Replica exited with exit code: 101

Additional info: A fresh install of dfx on an Ubuntu VM does not have this issue.
There are also details on the issue from another user in the forum: https://forum.dfinity.org/t/bug-dfx-start-upgrade-fail-on-arch-linux/545

Hide gas limit argument in dfx

A developer can use floats in calls via `dfx`

Error when accessing frontend in 0.5.5

From Zendesk:

After upgrading to 0.5.5 im getting this error when trying to access the canister frontend. I’m on macOS 10.13.6. I already deleted .dfx/state in the project direcotry and reinstalled dfx.

Also dfx throws errors, even though the canister was installed correctly:

Apr 05 23:02:29.381 WARN Could not perform query on canister: IC0301: Canister ic:B5008CEB5C40C41D42 not found, Application: Http Handler

An error happened:
TypeError: e.Service is not a function
    at t.default (data:text/javascript;base64,LyohIEZvciBsaWNlbnNlIGluZm9ybWF0aW9uIHBsZWFzZSBzZWUgaW5kZXguanMuTElDRU5TRSAqLwohZnVuY3Rpb24oZSl7dmFyIHQ9e307ZnVuY3Rpb24gbihyKXtpZih0W3JdKXJldHVybiB0W3JdLmV4cG9ydHM7dmFyIGw9dFtyXT17aTpyLGw6ITEsZXhwb3J0czp7fX07cmV0dXJuIGVbcl0uY2FsbChsLmV4cG9ydHMsbCxsLmV4cG9ydHMsbiksbC5sPSEwLGwuZXhwb3J0c31uLm09ZSxuLmM9dCxuLmQ9ZnVuY3Rpb24oZSx0LHIpe24ubyhlLHQpfHxPYmplY3QuZGVmaW5lUHJvcGVydHkoZSx0LHtlbnVtZXJhYmxlOiEwLGdldDpyfSl9LG4ucj1mdW5jdGlvbihlKXsidW5kZWZpbmVkIiE9dHlwZW9mIFN5bWJvbCYmU3ltYm9sLnRvU3RyaW5nVGFnJiZPYmplY3QuZGVmaW5lUHJvcGVydHkoZSxTeW1ib2wudG9TdHJpbmdUYWcse3ZhbHVlOiJNb2R1bGUifSksT2JqZWN0LmRlZmluZVByb3BlcnR5KGUsIl9fZXNNb2R1bGUiLHt2YWx1ZTohMH0pfSxuLnQ9ZnVuY3Rpb24oZSx0KXtpZigxJnQmJihlPW4oZSkpLDgmdClyZXR1cm4gZTtpZig0JnQmJiJvYmplY3QiPT10eXBlb2YgZSYmZSYmZS5fX2VzTW9kdWxlKXJldHVybiBlO3ZhciByPU9iamVjdC5jcmVhdGUobnVsbCk7aWYobi5yKHIpLE9iamVjdC5kZWZpbmVQcm9wZXJ0eShyLCJkZWZhdWx0Iix7ZW51bWVyYWJsZTohMCx2YWx1ZTplfSksMiZ0JiYic3RyaW5nIiE9dHlwZW9mIGUpZm9yKHZhciBsIGluIGUpbi5kKHIsbCxmdW5jdGlvbih0KXtyZXR1cm4gZVt0XX0uYmluZChudWxsLGwpKTtyZXR1cm4gcn0sbi5uPWZ1bmN0aW9uKGUpe3ZhciB0PWUmJmUuX19lc01vZHVsZT9mdW5jdGlvbigpe3JldHVybiBlLmRlZmF1bHR9OmZ1bmN0aW9uKCl7cmV0dXJuIGV9O3JldHVybiBuLmQodCwiYSIsdCksdH0sbi5vPWZ1bmN0aW9uKGUsdCl7cmV0dXJuIE9iamVjdC5wcm90b3R5cGUuaGFzT3duUHJvcGVydHkuY2FsbChlLHQpfSxuLnA9IiIsbihuLnM9Mil9KFtmdW5jdGlvbihlLHQsbil7InVzZSBzdHJpY3QiO2UuZXhwb3J0cz1uKDUpfSxmdW5jdGlvbihlLHQsbil7InVzZSBzdHJpY3QiO3ZhciByPU9iamVjdC5nZXRPd25Qcm9wZXJ0eVN5bWJvbHMsbD1PYmplY3QucHJvdG90eXBlLmhhc093blByb3BlcnR5LGk9T2JqZWN0LnByb3RvdHlwZS5wcm9wZXJ0eUlzRW51bWVyYWJsZTtmdW5jdGlvbiBhKGUpe2lmKG51bGw9PWUpdGhyb3cgbmV3IFR5cGVFcnJvcigiT2JqZWN0LmFzc2lnbiBjYW5ub3QgYmUgY2FsbGVkIHdpdGggbnVsbCBvciB1bmRlZmluZWQiKTtyZXR1cm4gT2JqZWN0KGUpfWUuZXhwb3J0cz1mdW5jdGlvbigpe3RyeXtpZighT2JqZWN0LmFzc2lnbilyZXR1cm4hMTt2YXIgZT1uZXcgU3RyaW5nKCJhYmMiKTtpZihlWzVdPSJkZSIsIjUiPT09T2JqZWN0LmdldE93blByb3BlcnR5TmFtZXMoZSlbMF0pcmV0dXJuITE7Zm9yKHZhciB0PXt9LG49MDtuPDEwO24rKyl0WyJfIitTdHJpbmcuZnJvbUNoYXJDb2RlKG4pXT1uO2lmKCIwMTIzNDU2Nzg5IiE9PU9iamVjdC5nZXRPd25Qcm9wZXJ0eU5hbWVzKHQpLm1hcCgoZnVuY3Rpb24oZSl7cmV0dXJuIHRbZV19KSkuam9pbigiIikpcmV0dXJuITE7dmFyIHI9e307cmV0dXJuImFiY2RlZmdoaWprbG1ub3BxcnN0Ii5zcGxpdCgiIikuZm9yRWFjaCgoZnVuY3Rpb24oZSl7cltlXT1lfSkpLCJhYmNkZWZnaGlqa2xtbm9wcXJzdCI9PT1PYmplY3Qua2V5cyhPYmplY3QuYXNzaWduKHt9LHIpKS5qb2luKCIiKX1jYXRjaChlKXtyZXR1cm4hMX19KCk/T2JqZWN0LmFzc2lnbjpmdW5jdGlvbihlLHQpe2Zvcih2YXIgbixvLHU9YShlKSxjPTE7Yzxhcmd1bWVudHMubGVuZ3RoO2MrKyl7Zm9yKHZhciBzIGluIG49T2JqZWN0KGFyZ3VtZW50c1tjXSkpbC5jYWxsKG4scykmJih1W3NdPW5bc10pO2lmKHIpe289cihuKTtmb3IodmFyIGY9MDtmPG8ubGVuZ3RoO2YrKylpLmNhbGwobixvW2ZdKSYmKHVbb1tmXV09bltvW2ZdXSl9fXJldHVybiB1fX0sZnVuY3Rpb24oZSx0LG4peyJ1c2Ugc3RyaWN0IjtPYmplY3QuZGVmaW5lUHJvcGVydHkodCwiX19lc01vZHVsZSIse3ZhbHVlOiEwfSk7Y29uc3Qgcj1uKDMpLGw9bigwKSxpPW4oNik7bigxMCk7Y2xhc3MgYSBleHRlbmRzIGwuQ29tcG9uZW50e2NvbnN0cnVjdG9yKGUpe3N1cGVyKGUpLHRoaXMuc3RvcHBlZD0hMSx0aGlzLnN0YXRlPXt9fWFzeW5jIGRvUG9wdWxhdGUoKXtsZXQgZT1kb2N1bWVudC5nZXRFbGVtZW50QnlJZCgibmV3RW50cnlXaWR0aCIpLnZhbHVlLHQ9ZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoIm5ld0VudHJ5SGVpZ2h0IikudmFsdWU7ci5kZWZhdWx0LnBvcHVsYXRlKHBhcnNlSW50KGUsMTApLHBhcnNlSW50KHQsMTApKX1hc3luYyBnZXRVbml2ZXJzZSgpe2RvY3VtZW50LmdldEVsZW1lbnRCeUlkKCJuZXdFbnRyeVdpZHRoIikudmFsdWU9cGFyc2VJbnQoYXdhaXQgci5kZWZhdWx0LmdldF93aWR0aCgpLDEwKSxkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgibmV3RW50cnlIZWlnaHQiKS52YWx1ZT1wYXJzZUludChhd2FpdCByLmRlZmF1bHQuZ2V0X2hlaWdodCgpLDEwKX1hc3luYyBkb1N0YXJ0KCl7ci5kZWZhdWx0LnN0YXJ0KCl9YXN5bmMgZG9SZW5kZXIoKXtjb25zdCBlPWRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCJnYW1lLW9mLWxpZmUtY2FudmFzIiksdD1hc3luYygpPT57ZS50ZXh0Q29udGVudD1hd2FpdCByLmRlZmF1bHQucmVuZGVyKCk7bGV0IG49YXdhaXQgci5kZWZhdWx0LmdldF91bml2ZXJzZSgpLGw9YXdhaXQgci5kZWZhdWx0LnRpY2soKTt0aGlzLnJlcUlkPXJlcXVlc3RBbmltYXRpb25GcmFtZSh0KSxKU09OLnN0cmluZ2lmeShuKSE9SlNPTi5zdHJpbmdpZnkobCkmJjEhPXRoaXMuc3RvcHBlZHx8Y2FuY2VsQW5pbWF0aW9uRnJhbWUodGhpcy5yZXFJZCl9O3JlcXVlc3RBbmltYXRpb25GcmFtZSh0KSx0aGlzLnN0b3BwZWQ9ITF9YXN5bmMgc3RvcFJlbmRlcigpe3RoaXMuc3RvcHBlZD0hMH1hc3luYyByZW5kZXJDdXJyZW50KCl7ZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoImdhbWUtb2YtbGlmZS1jYW52YXMiKS50ZXh0Q29udGVudD1hd2FpdCByLmRlZmF1bHQucmVuZGVyKCl9cmVuZGVyKCl7cmV0dXJuIGwuY3JlYXRlRWxlbWVudCgiZGl2Iix7Y2xhc3NOYW1lOiJuZXctZW50cnkifSxsLmNyZWF0ZUVsZW1lbnQoImRpdiIsbnVsbCxsLmNyZWF0ZUVsZW1lbnQoImgxIixudWxsLCJHYW1lIG9mIExpZmUiKSxsLmNyZWF0ZUVsZW1lbnQoImRpdiIsbnVsbCwiUG9wdWxhdGUgdGhlIHVuaXZlcnNlOiIsbC5jcmVhdGVFbGVtZW50KCJ0YWJsZSIsbnVsbCxsLmNyZWF0ZUVsZW1lbnQoInRyIixudWxsLGwuY3JlYXRlRWxlbWVudCgidGQiLG51bGwsIldpZHRoOiIpLGwuY3JlYXRlRWxlbWVudCgidGQiLG51bGwsbC5jcmVhdGVFbGVtZW50KCJpbnB1dCIse2lkOiJuZXdFbnRyeVdpZHRoIn0pKSksbC5jcmVhdGVFbGVtZW50KCJ0ciIsbnVsbCxsLmNyZWF0ZUVsZW1lbnQoInRkIixudWxsLCJIZWlnaHQ6IiksbC5jcmVhdGVFbGVtZW50KCJ0ZCIsbnVsbCxsLmNyZWF0ZUVsZW1lbnQoImlucHV0Iix7aWQ6Im5ld0VudHJ5SGVpZ2h0In0pKSkpLGwuY3JlYXRlRWxlbWVudCgiYnV0dG9uIix7b25DbGljazooKT0+dGhpcy5kb1B

Note: full error sent to @hansl

A developer can make signed requests with `dfx`

A developer can code generate an agent from a running canister

Frontend flag not working as expected/documented

From community member:

Shouldn't "--frontend false" prevent front end project files being created if nodejs is already installed?
https://sdk.dfinity.org/developers-guide/cli-reference.html#_dfx_new

dfx new hello --frontend false
error: Found argument 'false' which wasn't expected, or isn't valid in this context

USAGE:
dfx new <project_name> --frontend

Part of documentation they’re referring to:
Installs the template frontend code for the default project canister. The default value for the flag is true if node.js is currently installed on your local computer. If node.js is not currently installed, you can set this flag to true to attempt to install node.js and the template file when creating the project or you can set the flag to false to skip the installation of template frontend code entirely.

HI Hans, can you clarify the use case for the flag? Does it still exist? I don’t think I tested the behavior (because uninstalling and reinstalling node.js--from what I could tell--is far more cumbersome than it sounds like it would be) or if I did test it at the time, I don’t remember exactly what happened…

Dfx config command changes the order of fields in dfx.json

This was seen after using dfx config dfx "0.4.0" in a new project created using dfx new

Is this really a bug or applicable? I haven’t experienced it/don’t recall seeing this lately.

Yes it’s a bug. The order is alphabetized when using dfx config. We use it once when creating the frontend, that’s why most of the time it’s already alphabetized. But it shouldn’t be.

This is a really hard problem to fix. Let’s punt this for later.