Dfx deploy --network ic ➡️Canister x trapped: unreachable

As the title suggests, I’m seeing an error on dfx deploy that’s preventing me from deploying to mainnet. I haven’t come up with any ideas about what could be going on. Input appreciated! Maybe I’ll try a different dfx version later today… :thinking:

Note: The canister in question is running on IC just fine. I can hit it in the browser and everything’s functional. :white_check_mark:

❯ sudo dfx -v deploy --network ic
Deploying all canisters.
All canisters have already been created.
Building canisters...
Building frontend...
Running "npm" "run" "build"...
The following changes are being made to your tsconfig.json file:
  - compilerOptions.paths must not be set (aliased imports are not supported)

Installing canisters...
Upgrading code for canister backend, with canister_id X
Upgrading code for canister frontend, with canister_id Y
The invocation to the wallet call forward method failed with the error: An error happened during the call: 5: Canister Y trapped: unreachable

If I am reading the message and output correctly, the error seems to come from call not from deploy. That’s consistent with what I see listed, and you being able to reach it with your browser.

I’m not sure what’s happening, but it’s possible that you aren’t doing --network ic on your dfx call invocation, and its trying to do the default, and look locally for the canister? That could explain the output, perhaps.

BTW/FYI – Another alternative to dfx call on your deployed canister is ic-repl, which will TAB-based autocomplete for issuing calls to the deployed canister, either local or not.

1 Like

Sorry, not sure what you mean WRT dfx call. I’m not explicitly using that command anywhere. The error message is in response to dfx deploy --network ic.

Adding some colour and updates. This is for an asset canister.

I thought perhaps my “unreachable” error may have to do with the Motoko Prelude library’s unreachable() method/type, but asset canisters are written in rust. Rust has unreachable, but I read through the asset canister source and there are no uses of it. Perhaps I’m hitting some unreachable expression elsewhere in IC? Will investigate.

I was able to start a deployment of the exact same asset canister code by creating a new canister. Unfortunately that failed after running out of cycles during deployment twice: I have way too many big-ass images in this canister. I will isolate and try again, but seems possible that this issue has nothing to do with the canister’s code, based on initial results here.

I also verified a) I own the canister, b) I’m addressing the canister correctly, c) the canister has cycles.

Wish there was a better traceback! 🧑‍💻

Yes, I see. My mistake. Thanks for correcting my mischaracterization.

But as the error says, there is an implicit call occurring, IIUC. It is hidden by dfx, and it involves a wallet canister that contains your cycles for the deployment.

This use of ic-repl makes the call (to your wallet, to install the canister on your behalf) more explicit:

1 Like

Regarding a traceback for dfx deploy, perhaps file an issue for more fine-grained logging?

In the meantime, you can use ic-repl as an alternative to dfx deploy, and it will give you a different way of experiencing errors, if any.

Thanks for your notes, Matt. Where should I file an issue for dfx where that might be picked up? I’m having a look at ic-repl, but I’ve never touched rust and this repo doesn’t event really document what it is: I imagine it’s going to take a lot of hitting my head on against the wall to getting anything useful out of.

This is a bone-stock asset canister and wallet canister. Weird AF that it’s throwing a totally opaque error.

Talking with @kpeacock in the Discord today, it seems the SDK isn’t open source yet, so I don’t think there’s a great place to file a “better error output for dfx” issue. Specifically, I would like to know the line of code that’s throwing this unreachable error. As far as I can tell, there isn’t a better place to track this issue than here in the forum. I might just have to destroy the canister and redeploy it (bye bye, cycles.)

Perhaps this is my unreachable 🤷 cycles-wallet/build.rs at 1bb53cdd041896c67291848a07a99d416c3ce9c1 · dfinity/cycles-wallet · GitHub

After a month of a bricked can, I chatted with @ericswanson and he found a solution:

❯ dfx canister --network ic install --mode=reinstall

For any of you who try this method, be sure to specify which canister to reinstall! So something like

dfx canister --network ic install --mode=reinstall frontend

The reason is that reinstalling a canister this way will discard all data in that canister. This is ok for asset canisters, because dfx will just re-upload the assets right after reinstalling the canister wasm.