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
1 Like

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.

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:

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
1 Like

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.