Upon timeout (either through internet loss or server connection loss), cinch replays already-executed messages and commands. about cinch HOT 3 OPEN

For me, I set start_automatically: false on Timer (passed to constructor) to deal with this

from cinch.

@petertseng I've seen this happen with many timers as well. Should start_automatically: false be the default, do you think?

from cinch.

start_automatically

Interesting question. I use timers for two things:

1. Do something on a regular basis. I usually use DSL timer method to set these. start_automatically should probably be true here. I want the bot to keep doing the thing if it gets disconnected and reconnected.
2. Do something a certain time in the future once (perhaps this generalises to N times). I usually use Timer Helper to set these. start_automatically should probably be false here. That will stop the bot from re-doing the thing if it gets reconnected.

I personally think unconditional start_automatically: false would trip up too many people who use timers for the first use (automatically do something periodically).

But based on those above uses of timers, one might imagine some possible solutions:

• Keep the DSL timer method as-is (start_automatically: true default). Make the Helper Timer method default to start_automatically: false.
• If num_shots is a finite number, start_automatically: false by default. If it's infinite, start_automatically: true by default.
• Other solution I did not think of.

stop_automatically

There's an interesting snag here with the second kind of timer (do something once at some time in the future).

Let's say at t=0 I ask for a timer to fire in 300 seconds. One could reasonably expect that this timer fires at time t=300. But then the bot gets disconnected and reconnected at t=200. In that case, what should the behaviour be? If start_automatically is false, the timer never fires. If start_automatically is true, the timer fires at t=500 instead. Neither seems to be what was asked for. This seems important for one-shot timers since if it's scheduled once, someone probably cares about the time between schedule and the time between fire.

I just have my bot reschedule the timer at the correct remaining time on reconnect, but I guess I could have set stop_automatically to false instead so that disconnecting doesn't stop the timer. So Cinch doesn't need to try to do the reschedule.

So based on that, maybe stop_automatically should be given the same treatment as start_automatically (whatever that may be).

from cinch.