If throttle time is set to 0.0 (e.g. in tests) and the reported time
since last dequeue is also 0.0 (maybe because the timer resolution is
too low), takeMsg would throttle. This would make tests fail because
they expect messages immediately.
This issue was observed on Windows 10 20H2 with both a mingw-w64 Python
v3.8.9 from MSYS2 and several version of official Python v3.x.
Confirmed at least as far back as
aa98d987a7.
Since it's a non-integer comparison, the change shouldn't have any
observable effect in normal operation.
Otherwise, if some IP addresses don't work (eg. all odd ones), the bot will
consecutively fail because it can't connect, then connect + get STS + reconnect,
then fail again, then connect + get STS, etc.
FAIL: testMoreIsCaseInsensitive (Misc.test.MiscTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File /home/travis/virtualenv/python3.8-dev/lib/python3.8/site-packages/supybot/test.py, line 214, in runTest
originalRunTest()
File ./plugins/Misc/test.py, line 260, in testMoreIsCaseInsensitive
self.assertNotError('more %s' % nick.upper())
File /home/travis/virtualenv/python3.8-dev/lib/python3.8/site-packages/supybot/test.py, line 355, in assertNotError
m = self._feedMsg(query, **kwargs)
File /home/travis/virtualenv/python3.8-dev/lib/python3.8/site-packages/supybot/test.py, line 526, in _feedMsg
response = self.irc.takeMsg()
File /home/travis/virtualenv/python3.8-dev/lib/python3.8/site-packages/supybot/log.py, line 368, in m
return f(self, *args, **kwargs)
File /home/travis/virtualenv/python3.8-dev/lib/python3.8/site-packages/supybot/irclib.py, line 1308, in takeMsg
assert not msg.tagged('emulatedEcho')
AssertionError
I don't understand why it's happening or why it's only that specific test,
but there we go.
Plugins implementing inFilter do not set receivedAt, so incoming messages
rewritten by inFilter would be detected as echo messages, and ignored
by most plugins.
This reverts commit 1fe414764c.
I initially wrote that commit so that plugins with echoMessage=True can
get the nick/prefix from the message (eg. the SkypeRelay plugin in my
personal repo).
Unfortunately, this breaks any test that does equality comparison on
between the result of getMsg()/takeMsg() and an IrcMsg object they
crafted themselves.
Additionally, the filled in nick and prefix might be inaccurate if the
bot changes nick/host at the same time. So instead plugins should check
for the None value.
(Also, editing IrcMsgs on the fly like this isn't great, and the commit
forgot to reset the `_str` attribute.)
echo-message ended up in self.state.capabilities_req even though it wasn't
requested, so the bot was stuck in state:
"Waiting for ACK/NAK of capabilities: {'echo-message'}".
Plugin can opt in to getting echo messages by setting the class attribute
'echo_message = True' if they want to get echos.
This defaults to False in order not to break existing plugins, and because
they usually don't need it (there's outFilter for most cases).
If on an insecure connection: reconnect.
If on a secure connect: store it and do nothing else.
For now, stored STS policies are not read when connecting to an
insecure server.
