Skip to main content
Archway DocsDocs

Troubleshooting Development Issues

Here you'll find instructions for troubleshooting common issues and problems that can occur during Archway development.

General Errors​

Process exited with code 1 (ChildProcess)​

There are times during development where you may receive unclear error responses from the developer CLI. This can be because the error response itself doesn't explain what part of the command failed. These errors are usually triggered by Node's Child Process module panicking and failing to complete a Promise.

Failed to deploy project
Error: Process exited with code 1
at ChildProcess.done (/home/user/.nvm/versions/node/v17.9.0/lib/node_modules/@archwayhq/cli/node_modules/promisify-child-process/index.cjs:70:19)
at ChildProcess.emit (node:events:527:28)
at maybeClose (node:internal/child_process:1090:16)
at Process.ChildProcess._handle.onexit (node:internal/child_process:302:5)

To understand the real source of the error, you'll need to execute your command with some debugging flags enabled. To understand how to enable debugging on the developer CLI, review our debugging instructions.

SyntaxError: Invalid or unexpected token​

You'll get this error response for all Archway commands, if the NPM package for the developer CLI was installed using a legacy version of Node.js. To solve this problem update your Node.js and reinstall the NPM package. For information about which versions of Node.js are supported, review the developer installation instructions.

Project Creation​

Error: no such subcommand​

When creating a new project with the archway new command, if you encounter the error response saying error: no such subcommand: run-script or error: no such subcommand: generate, it means you're missing a required Cargo package.

To fix the error, make sure you've installed both cargo-generate and cargo-run-script.

Example:

cargo install cargo-generate --features vendored-openssl
cargo install cargo-run-script

Deployment Failures​

CosmWasm Rust optimizer fails​

If you are having trouble with the cosmwasm/rust-optimizer, you may need to update Cargo.toml at the root of your project with another version of the optimizer.

Example (Old Cargo.toml): 

[package.metadata.scripts]
optimize = """docker run --rm -v "$(pwd)":/code \
  -e CARGO_TERM_COLOR=always \
  --mount type=volume,source="$(basename "$(pwd)")_cache",target=/code/target \
  --mount type=volume,source=registry_cache,target=/usr/local/cargo/registry \
  cosmwasm/rust-optimizer:0.12.5
"""

Example (Updated Cargo.toml):

[package.metadata.scripts]
optimize = """docker run --rm -v "$(pwd)":/code \
  -e CARGO_TERM_COLOR=always \
  --mount type=volume,source="$(basename "$(pwd)")_cache",target=/code/target \
  --mount type=volume,source=registry_cache,target=/usr/local/cargo/registry \
  cosmwasm/rust-optimizer:0.12.6
"""

Deployment stuck at downloading WASM​

This could be an issue with the RPC node. If your deployment is continually getting stuck downloading wasm, try downloading it manually or use the flag --no-verify to skip checksum verification entirely.

To download and verify the wasm upload manually, you'll need to know your code id which you can get by searching the block explorer for your upload transaction by its hash, or using the archway history command if your config.json was successfully updated after the transaction. Once you've got the code id, see below for an example of how to download and verify your wasm storage transaction.

Example:

archwayd query wasm code $YOUR_CODE_ID --node "https://rpc.constantine-1.archway.tech:443" download.wasm
$ diff artifacts/YOUR_DOCKER_WASM_OUTPUT_FILE.wasm download.wasm

WASM stores but contract fails to instantiate​

The most common reason for deployments failing at instantiation is incorrect arguments submitted to the --args flags. See test passed but on-chain tx fails.

Testing​

Can't print data from tests​

Ever wondered why you can't use macros like println! and dbg! to write to stdout from tests? This happens because Rust tests hide the stdout stream of successful tests to keep test output tidy. You can disable this behavior by passing the --nocapture option to the test binary or to cargo test (but, in this case after -- – see below):

Examples:

$ rustc --test main.rs; ./main

running 1 test
test test ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured

$ ./main --nocapture

running 1 test
Hidden output
test test ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

$ cargo test -- --nocapture

running 1 test
Hidden output
test test ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

If you need to make this the default behavior of the archway test command, you can do so by modifying the value of developer.scripts.test in config.json at the root of your project.

Example:

Default JSON (excerpt)

{
  "developer": {
    "scripts": {
      "test": "cargo unit-test",
      "build": "cargo build",
      "optimize": "cargo run-script optimize",
      "wasm": "cargo wasm",
      "query": "archwayd query wasm",
      "tx": "archwayd tx wasm execute"
    }
  }
}

Updated JSON (excerpt)

{
  "developer": {
    "scripts": {
      "test": "cargo unit-test -- --nocapture",
      "build": "cargo build",
      "optimize": "cargo run-script optimize",
      "wasm": "cargo wasm",
      "query": "archwayd query wasm",
      "tx": "archwayd tx wasm execute"
    }
  }
}

Test passed but on-chain tx fails​

A common reason for this happening is one or more errors in the arguments passed to the --args flag in the archway deploy or archway tx command.

There are several things to consider when formulating your JSON arguments to pass to the --args flag. Below are a few use cases that will cause instantiation to fail.

1) Invalid JSON

If your arguments are not submitted in valid JSON format the instantiation will fail. The full error response looks like this:

error: option '-a, --args <value>' argument '{count:0}' is invalid. Please inform a valid JSON string.

2) Invalid JSON key

If your JSON values are all correct, but one or more of their keys are not recognized, you'll get an Error parsing into type response from the developer CLI. The full error message might look like this:

Error: rpc error: code = InvalidArgument desc = failed to execute message; message index: 0: Error parsing into type increment_project::msg::InstantiateMsg: missing field `count`: instantiate wasm contract failed: invalid request

3) Invalid JSON value

If the JSON keys are correct, but one or more values are not, you'll get an Invalid type error response from the developer CLI. The full error message looks like this:

Error: rpc error: code = InvalidArgument desc = failed to execute message; message index: 0: Error parsing into type increment_project::msg::InstantiateMsg: Invalid type: instantiate wasm contract failed: invalid request
tip

For help finding the source of problems with transaction aguments, see how to debug failing transactions for more information about regenerating your schema.

RPC Errors​

My code used to work, I didn't change anything​

This can happen if the RPC node you're connecting is running a different version of archwayd.

If you are using the Docker version of archwayd, pull again from Docker Hub to get the latest image.

Example: 

 docker pull archwaynetwork/archwayd:constantine

If you have installed archwayd locally from GitHub, you will need to pull the latest changes and reinstall archwayd.

Example:

git fetch
git checkout tags/${tag_name} # e.g. git checkout tags/v0.0.5
make install

InvalidArgument desc = account sequence mismatch​

Error: rpc error: code = InvalidArgument desc = account sequence mismatch, expected 13898, got 13884: incorrect account sequence: invalid request

The above error isn't caused by your code. It seems to occur during periods of high network activity. We are tracking the problem in this GitHub thread.

We are actively looking for ways to solve it, but in the meantime your best bet is to continue broadcasting the transaction until it works. In some cases, you may also be able to get your transaction through by switching the --broadcast-mode flag sent to archwayd. The developer CLI currently defaults to --broadcast-mode block, to switch to --broadcast-mode sync you'll need to call archwayd directly.

Example (Instantiate):

archwayd tx wasm instantiate ${YOUR_CODE_ID} '{"key":"value"}' --from ${YOUR_WALLET_NAME} --label ${YOUR_DAPP_LABEL} --node "https://rpc.constantine-1.archway.tech:443" --chain-id "constantine-1" --gas-prices "0.001uconst" --gas "auto" --gas-adjustment 1.3 --broadcast-mode sync -y

Example (Tx):

archwayd tx wasm execute ${YOUR_CONTRACT_ADDRESS} '{"entrypoint":{}}' --from ${YOUR_WALLET_NAME} --node "https://rpc.constantine-1.archway.tech:443" --chain-id "constantine-1" --gas-prices "0.001uconst" --gas "auto" --gas-adjustment 1.3 --broadcast-mode sync -y

Permissions Errors​

Docker setups are the source of most permissions errors, and by default Docker runs as the root user. If you're not running the Docker daemon in rootless mode you may need to install the Archway developer CLI as root, or give your user permissions to the Archway directory on your filesystem.

Example: 

sudo chown YOUR_USERNAME:YOUR_GROUPNAME -R ~/.archway

This problem can be avoided by installing archwayd locally. For those instructions see: install archwayd from source