Timer API redundancy is causing excessive burn rate

I recently implemented the timer API into my application. I’ve noticed the cycles burn rate has been continuously increasing. I suspect what is happening is the recurringTimer() function that I defined within the canister actor is creating a new instance of the timer every time I deploy an update to the canister- resulting in the recurringTimer() function having multiple instances of the same function being fired by different timers. The solution is to call the cancelTimer() function with the timerId of the redundant timers being passed into the cancelTimer() function as the argument.

The issue, however, is that I don’t have those timerId’s saved anywhere. So, I can’t cancel them. Is there any way for me to be able to query the canister in order to retrieve the ID’s of the active timers that are present? or is there any way for me to deactivate all of the timers at once?

1 Like

I’m pretty sure all timers get cancelled automatically (just deleted by the system) after each deploy.

I thought so too, but apparently, if you define the timers within an actor, but outside of a function, the timer doesn’t get cancelled upon redeploying (Not sure if thats a bug or a feature). I was able to confirm this by setting up an experiment in which I define a Nat as a stable variable and I set a timer to increment the Nat by a value of 1 every 30 seconds. With each redeploy, the Nat is incremented more and more within the 30 second time span.

I did find a solution though. To cancel all instances of the Timer, all I had to do was delete the code where I defined the timer, then deploy the canister. By doing that, all of the effects of the timer that I set have ceased.

3 Likes

Are you using Motoko? I wonder if it has different timer semantics than Rust in this case.

I am indeed using Motoko.

I am using Motoko and Timers a lot and haven’t noticed that behavior.
Could you put the test in a Motoko playground?

I made one quickly, it doesn’t look like there is a problem after upgrading multiple times

At first, I didn’t show the time only the counter and it was incrementing with 2 sometimes no matter how fast I clicked on the get button. But with the time elapsed, you can see it’s okay. Queries not returning an updated result - that must be some other issue

My guess is that the issue can’t be replicated in Motoko playground. I can assure you that I experienced the issue upon deploying my canister to the IC from my computer.

The playground uses the latest version of Motoko. Everything else should be the same, its not some kind of emulator. Maybe your Motoko is old and there is a bug inside it?

I’m currently using dfx version 0.15.1.

@infu , I just attempted to replicate the bug from my canister and I’m not seeing it either. @diegop has someone already resolved this issue?