Open Zarthus opened 7 years ago
For me, I set start_automatically: false
on Timer (passed to constructor) to deal with this
@petertseng I've seen this happen with many timers as well. Should start_automatically: false be the default, do you think?
start_automatically
Interesting question. I use timers for two things:
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.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:
timer
method as-is (start_automatically: true
default). Make the Helper Timer
method default to start_automatically: false
.num_shots
is a finite number, start_automatically: false
by default. If it's infinite, start_automatically: true
by default.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).
The title is a bit longwinded, so allow me to elaborate:
In the cinch timebomb plugin, the bot will re-kick users previously kicked upon disconnect.
This issue is not specific to the cinch timebomb plugin, but it is a relatively minimal example that demonstrates reproducability. In some of my custom plugins I've seen it happening as well, just on a less annoying scale.
Now lets say this plugin has kicked three or four people, and the bot disconnects because server.network.net is being restarted. Upon reconnection, the bot will proceed to re-kick all these people.
From the timebomb plugin, at one of these events:
This is not just limited to kicks, and I believe I've seen it happen with mode changes as well. It might be related to timers.
This issue has been around for some time, I don't know when exactly, but it seems to at least happen in 2.3.x, it just seems like nobody has been too bothered by it to report it. I've seen several cinch bots have similar behaviour, including my own.
A restart of cinch (killing the process and booting it back up again) fixes the problem.