Loss of cycles when canister creation fails?

Developers
1

I have figured out that when the canister creation fails, my cycles are lost.

I start with a the following balance in my cycles ledger.

dfx cycles balance --ic
5.091 TC (trillion cycles).

I created a new canister in a dedicated subnet with a specific amount of cycles, but the process failed.

dfx canister create backend --subnet shefu-t3kr5-t5q3w-mqmdq-jabyv-vyvtf-cyyey-3kmo4-toyln-emubw-4qe --with-cycles 1T --ic
Creating canister backend…
created-at-time for canister backend is 1726416134008722000.
Error: Failed to create canister ‘backend’.
Caused by: Failed to create canister via cycles ledger.
Caused by: The replica returned an HTTP Error: Http Error: status 400 Bad Request, content type “text/plain; charset=utf-8”, content: Specified ingress_expiry not within expected range: Minimum allowed expiry: 2024-09-15 16:00:14.079120981 UTC, Maximum allowed expiry: 2024-09-15 16:05:44.079120981 UTC, Provided expiry: 2024-09-15 16:06:00 UTC

After that, I have 1T fewer cycles in the cycles ledger, and the canister is not created.”

dfx cycles balance --ic
4.091 TC (trillion cycles).

What am I doing wrong?

2

This may help: Lost cycles while minting a new cansiter

3

Okay thanks, but what does that mean?

In my case:

  • I created a canister and realized that I used the wrong subnet.
  • I deleted the canister and
  • created a new canister with a dedicated subnet

and this happened within a short time, meaning immediately after each step was completed.

How long do I need to wait for the steps to be completed? Shouldn’t there be a warning, considering there’s a risk of losing money?

In my case, I lost 2 x 1T before realizing the problem. Others could potentially lose even more.

1 Like
4

from my understanding you should have received the remaining cycles back after you deleted the canister on the wrong subnet.

to me it seems that “just” the deployment (of 2 different canisters?) on the specified subnet failed for you.

I am not sure what the term “soon enough” means. from what the Kapa AI tells me it should be around 24 hours. if my understanding is correct, you should run the following command again as soon as possible to secure the cycles given your example above:

  • dfx canister create backend --subnet shefu-t3kr5-t5q3w-mqmdq-jabyv-vyvtf-cyyey-3kmo4-toyln-emubw-4qe --with-cycles 1T --created-at-time 1726416134008722000 --ic

the --created-at-time value should reflect what the dfx logs printed out. so in case of 2 different canisters the value would most likely differ.

I agree that people should be aware/warned if such error occurs and cycles might get lost.

to avoid such scenario it might be better to split the deployment and the cycle top up into two different actions and just provide a minimal initial amount of cycles (if needed at all).

2 Likes