output the last contest winner again... just in case

[pironic]

If the bot talks too much then it gets flood blocked. If the contest winner announcement gets blocked... revolt.

If we log the message to console, then the admin could theoretically find it again.
or
If no contest was running, we could say the winner of the last contest when an admin typed /ballot.

[Reanmachine]

Curious, could we not find out what the chat flood protection is and gate the outbound messages in queue to make sure the bot never floods?

[pironic]

The problem with this is that we have asynchronous commands and queries
running. The bigger problem is that the real time server is what is
blocking the command from being sent... Not the front end. Which makes me
wonder about the possibility that is because we host so many broadcasts
from the same external ip... The real time server sees multiple clients and
blocks the most recent one. Even if we queue it perfectly, no gaurantee it
gets through.

Further testing /confirmation from GS would be needed. Maybe I'll talk to
Brian about it when I'm back from holidays.
On 2 Oct 2014 12:37, "Reanmachine" notifications@github.com wrote:

Curious, could we not find out what the chat flood protection is and gate
the outbound messages in queue to make sure the bot never floods?

—
Reply to this email directly or view it on GitHub
#10 (comment)
.