After topping up cycles and trying to run “dfx deploy --network ic”, i received the following messages:
Deploying all canisters.
Creating canisters…
Creating canister “XXXXXX”…
An error happened during communication with the replica: error sending request for url (https://ic0.app/api/v2/canister/rs3zr-XXXXX-XXXXX-XXXXX-cai/read_state): http2 error: protocol error: not a result of an error
Now, in my cycles wallet, I see an anonymous canister that I am unsure of how to use:
Anonymous Canister
r4zuz-XXXXX-XXXXX-XXXXX-cai
11000000000000 TC
How do I deploy to that specific canister? Are my cycles locked in a canister that I am unable to access due to the http2 error? Thank you!
Regarding the IDs – dfx is stashing the canister ID that you were assigned. I believe that something went wrong, however, before the Wasm could be uploaded. It seems like the failure happens between creating the ID and uploading the Wasm to that ID. Ordinarily, both would occur during deploy and you’d be able to interact with your canister after the deployment finishes. In this case, you’ve got a canister ID but I believe, no active canister code (no Wasm) uploaded there, IIUC.
Try doing tree .dfx/local.
For my project, I see a list of files with .did and .wasm as well as a canister_ids.json file.
Do you see a tree there with these files?
If so, then perhaps just redo the deploy again and see if the error persists. The canister IDs will not be recreated, IIUC.
If I run deploy again, it asks for 11T more cycles. I do see canister IDs in .dfx/local. This project was an example project from the list of tutorials that I am trying to deploy. I also see the .did and .wasm files.
Could it be an issue that I cloned a sample project?
Do you mind sharing the specific example you are using? I’ll try it myself, and see if there’s just some stale issues in that example that haven’t been addressed for the latest dfx version.
Perhaps you can separately try a local deployment? Both should work, and this doesn’t address the behavior you see on the IC network, but it may provide more information about what is happening.
What happens if you try this?
dfx start --clean --background (if you are not already running a local replica)
dfx deploy --no-wallet
That is use the local replica, not on the IC network (no --network=ic) and avoid the wallet factor entirely by saying --no-wallet
Looking back through the project, I did not clone a sample project. I used dfx new to create it. I am able to deploy and run the project locally. If I run dfx canister status locally, I get this output:
Not sure what is going on but I suspect dfx deploy has created and provisioned the canister, but failed to install the code.
Try something like
dfx canister --network ic install XXXXXX
(or see dfx canister --help)
And see what happens. You may need to specify a wallet to pay for the installation, unless it just uses the default wallet. (I’m no dfx expert, unfortunately).
Okay, the issue seems to be solved now w/o no cycles lost to the ether. After @matthewhammer suggested to run dfx canister status, it told me to run dfx canister --network ic create PROJECT_NAME which i did (spending 4T cycles). In my root folder, it created a canister_ids.json. I copied the format from the .dfx/local version and replaced the local id’s with the Anonymous Canister canister id’s listed in my Cycles Wallet. The project successfully deployed after that. Thank you @claudio and matthewhammer for the thoughtful responses!
here is the canister_ids.json file that was created in my root project folder: