Open dwhitacre opened 5 years ago
Probably won't prioritize this until core functionality is implemented.
I've seen in my other bots leveraging this library, that messages tend to fail to send when there is high activity with the bot, though I've seen them fail seemingly randomly in local testing as well.
messages always seem to fail when it is a duplicate as well... could technically be getting blocked from channel settings... need to handle this case
people notice this and it looks bad on the bot when messages dont send... lets do something about this soon
we should keep the low cost alternative of not verifying message were sent as well. sometimes we dont care if it was successful, especially if the command is something that doesnt really need a response every time.
At the moment, due to a limitation in the tmi library we are not able to guarantee that when we call
say
orwhisper
that the message is actually sent. The promises here only throw an error if the tmi failed to open a connection to twitch irc, but if the message didnt actually get written to IRC, it returns true regardless. Since tmi doesn't want to fix this as it would require theirsay
implementation to open multiple connections to twitch (a socket listener and the irc message send) (understandably), we need to implement our own system to guarantee message delivery in twitch chat.Since we already have multiple connections open to twitch we can do this pretty easily, but it will require a overhaul to how our current messaging system works. Atm we immediately call
say
when the twitchClient is instructed to. We'd want to instead, add the message to be sent to a message queue. These message would need a state of waiting to be sent, a fail counter, a success flag, a timeout etc. From here, we'd then periodically peek messages in the queue and call thetmi say
method. In our message handler, instead of ignoring messages sent by the bot itself, we'd monitor for messages that are currently in our message queue. If we see the message in our message queue we'd remove it from the queue. The message queue itself, would also need to a timeout for when it should retry to send the message, and a max retry limit before it drops the message from the queue altogether.