A developer on Juno encountered an issue when trying to top up a canister using the CMC canister. The CMC rejected the top-up with the error:
Call failed: Canister: xxxx-xxxx-cai Method: version (query) “Status”: “rejected”
“CanisterError” “Message”: "IC0501: Canister xxxx-xxxx-cai is unable to process query calls because it’s frozen.
What surprised me is that I managed to transfer cycles to the canister using the NNS dapp without using the CMC canister.
I’m not sure exactly how low on cycles the canister was before I topped it up, but I guess not zero given that I transferred 1 TCycles and its balance is now around 2 TCycles.
Has anyone else experienced such strange behavior with the CMC canister?
Checking the CMC’s cycles balance through the nns-root canister on the dashboard says the cmc cycles balance is greater than 6000T cycles, and calling a method on the cmc returns a successful response.
Is it possible this error is coming from a different canister (not the cmc)? because the cmc uses an update call for the notify_top_up method and this error comes from a query call.
I think the NNS dapp uses the cmc to convert icp into cycles.
That’s a good point. The topup (notify_top_up) was call through another canister however, the error message did not mention this “middle” canister at all.
You are right (did not double checked the code before posting the question). Even weirder then.
So yes maybe it was the “middle” canister but, we checked it and that particular canister was not frozen given that it still had 1.3 T Cycles.
First of all, the CMC is running on the NNS and just like any other canister on the NNS, it does not need to pay in cycles, so the concept of freezing is not applicable there.
Second, the error message is coming from when calling a query call on a canister (perhaps the target canister that the user thought they topped up but maybe they didn’t). It’s not the error message you’d see if a top up fails (as Levi pointed out the top up in CMC is happening through an update call).
Lastly,
that particular canister was not frozen given that it still had 1.3 T Cycles.
You cannot be sure just by the absolute number of cycles in the canister. Whether the canister is frozen is a combination of how long the freezing threshold is set and what are the idle cycles burned by the canister (due to compute allocation and memory used).
Ok but the user was administrating the canister in the UI. If the canister would have been frozen, they would have received other errors as other calls are performed in the UI to administrate the canister. So that’s another hint that the canister wasn’t frozen.