Swallowed 2 seperate 1 ICP deposits & no miners have spawned. No transaction history/ anything in wallet in order to check status/ see if my ICP reappears.
Does anyone know if there is an issue with subnet bkfrj-6k62g-dycql-7h53p-atvkj-zg4to-gaogh-netha-ptybj-ntsgw-rqe, I’m having a super hard time getting update calls to return. Ingress Expiry errors all over the place.
Tagging @SvenF because I see a post about subnets recently…apologies if you are not the right person. I’ve had auotf-hqaaa-aaaas-aem7q-cai trying to stop all night long. I’m guessing it is because I have a 5-minute recurring timer? And one is not finishing before the next? I’m guessing I’m bricked until the subnet frees up enough to let all the timers finish? Perhaps they stack infinitely?
I’m going to try to get a new canister ID on this subnet and redeploy with a different timer structure…is there any way to see how many open call contexts there are from the back end?
There are now 10k+ miners competing for compute resources, so your canister may have to wait a while until it gets scheduled, which can lead to things timing out. Have you tried setting a small compute allocation for your canister, and then trying to stop?
So, what does this all mean? It seems that Bob is working well, and there are over 10,000 canisters in competition. But what about the other projects running on the European Subnet?
Should we consider moving to a different Subnet, or is there a better solution for this situation?
The replica returned a rejection error: reject code CanisterError, reject message Cannot increase compute allocation to 1% due to insufficient cycles. At least 16_332_399_480_419 additional cycles are required., error code None
This seems very odd to me that it would not get scheduled over the course of hours. I’m curios if this might have something to do with the timer implementation in motoko. @ggreif or @claudio Do you all know if perhaps recurring timers have some kind of lower priority than other kind of calls?
@manu What effect will this 1% have on my cycle consumption? I just have to have a higher balance?
I think it did get scheduled, but not quickly enough. Stopping requests time out, I believe after 5 minutes. This is to avoid a situation where your canister would otherwise potentially be in a forever stopping state (eg because of outstanding call contexts).
To the replica there are only single-expiry timers. It is up to the replica how to schedule them. The Motoko RTS simply pulls as many individual timers from the priority queue (max 10 a.t.m.) as are expired and runs them, adding back recurring ones. Then it computes the next global expiry and adds it to the replica.