I’ve got a main canister (manager) that generates (sub) canisters. I would like to transfer the remaining cycles of these (sub) canisters, before deleting them but, I am not sure where I should call deposit_cycles?
In my manager, I have implemented following functions:
You can use dfx wallet send command of the wallet_send method to send a specific number of cycles to a specific canister. Keep in mind that the canister you specify must be a cycles wallet or have a wallet_receive method to accept the cycles.
If you have deployed a cycles wallet on the Internet Computer main network, you can use the dfx wallet send command to send cycles between canisters running on the network.
Thank you for your answers. I tried both ideas, moving the deposit_cycles to the sub-canister and the example of the motoko doc.
Good news, it works in a sample repo.
Bad news, it does not work in my app ().
Not sure the issue is linked to the auth or the permissions but, I think it definitely has to do with something like that. When I try to deposit the cycles from the sub containers I get an error that only the controllers of the canister … can control it even though I do set the controllers (update_settings) when I create the sub-canisters.
Still debugging…
Meanwhile, for those interested, here my sample repo that transfer cycles before deleting canisters a manager generate on the fly: GitHub - peterpeterparker/transfercycles
I have solved (I think) the above error only the controllers of the canister … can control it by also adding the sub-canister principal ID in the list of controllers (somehow I had it in my example but, not in my app).
Now I am facing the next error Canister (principal id of the sub-canister) trapped explicitly: could not perform call …
Looks like it’s making an unnecessary call to retrieve the status to discover the balance. Did you try just using (Experimental)Cycles.balance() instead? It’s synchronous, and doesn’t require the canister to be its own controller.
I’m not sure if this is still the case with dfx 0.8.0, but prior releases shipped with a local replica that would not charge any cycles for execution. If that is still the case, that could explain some difference in behaviour between testing on a local replica and running on the real network.
Thanks for the idea Claudio. This looks like promising. I tested on real network with my app (not the sample one) and did not face the error as above but got another one.
Canister pmtxw… attempted to send 897991667468 cycles when only 897991667468 were available in its balance
I will now try out your other suggestion to “leave some slack”. Not sure what value to use though, maybe 100000000000?
Yoohoo it worked out . On the real network, I was able to delete a canister and transfer remaining cycles to my principal. I checked the balance of my manager canister in NNS and did notice the cycles being credited !
To the remaining cycles of the sub-canister I subtract 100_000_000_000 which is currently the cost for the creation of a canister (see documentation). Not sure it cannot be less, I did not test.
I mark this post as the solution but, the credits go to @claudio ! Thanks a lot for the help
Also, it would be faster to inline the call to 'await b.id() ’ in ‘utils.mo’ by calling ‘Principal.fromActor(b)’ instead. Then you can delete the ‘id()’ function too. Awaits are not cheap.
Before going live, it will need some tests to find the best suitable value. I also hope it costs less as the current value I used is the most expensive, the one to create a canister. Added to my long list of TODOs
Freak I did not know it was possible to pass b to fromActor directly. Sure happy to drop any unnecessary await.
I just tested it too to finally set a correct value and from my tests the minimal cycles to retain to delete a canister is actually 4.1
note: 4_000_000 isn’t enough. I did not try all values between 4_000_000 and 4_100_000.
UPDATE: the amount of cycles to retain in order to delete a canister is not a static value but a dynamic value. I have rollbacked to a high threshold until that dynamic value can be determined.
I recently spent a few hours trying to replicate this working example locally, and while the “sub-canister” deletes successfully, it is not refunding the “manager” canister the cycles. Here’s my exact example.
public shared ({ caller = caller }) func delete(key: Text): async () {
// getCanisterIDIfExists is a helper function that prevents duplicate creation
switch(getCanisterIDIfExists(key)) {
case null {
Debug.print("canister for key=" # key # " does not exist");
};
case (?canisterId) {
let canisterPrincipal = Principal.fromText(canisterId);
let subCanister = actor(canisterId): actor { transferCycles: () -> async() };
Debug.print("transferring cycles for " # canisterId);
await subCanister.transferCycles();
Debug.print("transferred cycles for " # canisterId);
Debug.print("stopping & deleting canisterId=" # canisterId);
await IC.stop_canister({ canister_id = canisterPrincipal });
await IC.delete_canister({ canister_id = canisterPrincipal });
Debug.print("deleted " # canisterId);
}
};
};
How I’m testing this out (locally)
First I build my “manager” canister and deploy it to my local network.
Then I create a sub-canister through the “manager” canister by calling a create api I have defined on the “manager” canister. When I create a sub-canister, I’m passing 1T cycles to it and my “manager” canister is correctly losing 1T cycles. I can verify this after creating the canister by running dfx canister status
dfx canister status (on the manager canister) → Balance: 3_000_000_000_000 Cycles dfx canister status (on the sub-canister) → Balance: 1_000_000_000_000 Cycles
I then run the delete api I have pasted the code of above. As I do this I can also see the following logging (in my local dfx):
I then attempt to verify the canister transfer and deletion by running dfx canister status again dfx canister status (on the manager canister) → Balance: 3_000_000_000_000 Cycles dfx canister status (on the sub-canister) → Error: The replica returned an HTTP Error: Http Error: status 404 Not Found, content type "", content: Requested canister does not exist
Step 4. Shows that the sub-canister is being deleted successfully, but that 900_000_000_000 cycles from the sub-canister have not been refunded to the “manager” canister. It also doesn’t seem like these cycles are being refunded to the wallet either - so, where are they going (locally).
Follow up question(s) - in the case this is a bug
If this isn’t a bug in my code or proces, is this an issue with local vs. mainnet dfx? (i.e. this works on the main net, but not local).
If so, is there a way around this so that I can test this code as much as possible locally before deploying to main net in order to eliminate testing costs?
Confirmed that the solution provide above by @peterparker worked.
The issue I had spawned from how I was importing the management canister module into my main and child canister. The code ended up being nearly identical to the examples provided above
).
. On the real network, I was able to delete a canister and transfer remaining cycles to my principal. I checked the balance of my manager canister in NNS and did notice the cycles being credited !
