Thanks for the report. I’ll reach out to the owners of the top-up code.
I see that your canister has an availableCycles() query. It currently returns 6.1T
It seems that some of the cycles were deposited after you saw 4.3T. But that still doesn’t explain why the balance is not 11-12T now. Could it be that the canister transfers cycles to another canister while handling some update call or in a heartbeat?
No, nothing was added. I ran the top-up command again with 0.5 ICP and it worked that time, increasing cycles by about 2 trillion cycles. That’s why it has around 6 trillion now. So the 2 ICP did not get converted into cycles at all.
There is zero possibility canister was doing anything at that time. It was EXT v2 collection I’ve deployed for testing on live blockchain and have just deployed it before running the top-up command (to add in more cycles). I can share the code if required to you or the team (the code is not public), but like I said, nothing too specific in the canister code itself, nor was the canister doing anything at the time of using top-up command. This is not the first time this is happening to me with using top-up command. It has not worked before as well (however it was erroring out some months ago) and now it returns a success, deducts ICP tokens and does not deposit cycles (even though it says it did).
@AnonymousCoder : could it be that aiekw created these canister programmatically with the initial 2.4T balance around the time of the deposit? Or did you create these canisters manually and make aiekw their only controller?
The collection canister in question (aiekw) does deploy it’s asset canisters dynamically through code. However, the initial “minting” script in node failed due to not having enough cycles to create required asset canisters from the main “aiekw” canister and the script failed, after which I ran the command of top-up to add more cycles to the aiekw canister in order for it to be able to deploy the asset canisters. If those were created at the almost exact time of the issue, I guess it could’ve been possible that these 7.9 trillion cycles went into deploying those 3 asset canisters, but only if it was like at almost exact time, because I did later deposit more cycles and re-ran the minting script again which completed successfuly
Can’t tell anymore since they’ve been out for like 6-8 hours now, probably less than initial deposited amount if any But if I put together your info about balances of the 3 asset canisters it does seem to add up very close to 7.9 trillion that it said were deposited, although it is around 7.2 trillion when added together so I am not sure.
Cool! Thanks for checking. We are missing 0.7T = 7.9T - 7.2T cycles. There is a fee of 0.1T for creating a single canister, which explains 0.3T. After taking that into account we are missing 0.4T. I guess some of it was burned by execution and periodic charges for memory usage. Shall we consider the remaining as measurement noise?
Yeah I think that in this case it def might be possible that the canister took the deposited cycles and immediately made the asset canisters as soon as cycles were deposited and that’s the reason i never seen that 7.2 trillion cycles increase after the deposit. I will definitely keep my eyes open on this command in the future and report any issues if I find them! Thank you for shedding some light on this issue, much appreciated!