Describe the bug
The bot times out typically between 240-265 seconds. This is ~4 minutes, and the first ping (for freenode) is ~2 minutes.
To Reproduce
Steps to reproduce the behavior:
Start bot
Don't talk to the bot at all or chat at all
Wait until bot times out
Expected behavior
The bot stays active and responds to pings without error.
Desktop (please complete the following information):
OS: Fedora 29 XFCE
Browser: Hexchat IRC
Version: Development (master branch)
Screenshots
The bot lasted ~6 minutes 18 seconds, meaning the first ping happened ~2 minutes, and no pings for 4 minutes, OR it didn't respond to a ping within those 4 minutes.
Additional context
Errors have been noted immediately after a ping where the bot responds but any input from the IRC channel for 1 messages is improperly read as unknown. Very potentially an issue that the first ping is received and taken care of, but the second ping is ignored due to being read as unknown.
UPDATE: During debugging, I noticed that after a ping the response is handled, but not broken. Should another message come in, it starts in the middle of pull, immediately after stay_alive, but using the previous message.
Describe the bug The bot times out typically between 240-265 seconds. This is ~4 minutes, and the first ping (for freenode) is ~2 minutes.
To Reproduce Steps to reproduce the behavior:
Expected behavior The bot stays active and responds to pings without error.
Desktop (please complete the following information):
Screenshots
The bot lasted ~6 minutes 18 seconds, meaning the first ping happened ~2 minutes, and no pings for 4 minutes, OR it didn't respond to a ping within those 4 minutes.
Additional context
Errors have been noted immediately after a ping where the bot responds but any input from the IRC channel for 1 messages is improperly read as
unknown. Very potentially an issue that the first ping is received and taken care of, but the second ping is ignored due to being read as unknown.UPDATE: During debugging, I noticed that after a ping the response is handled, but not broken. Should another message come in, it starts in the middle of
pull, immediately afterstay_alive, but using the previous message.