New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MODE between WHO and RPL_WHOREPLY is lost #2562
Comments
I wonder if modern Unreal has the same interleaving behavior, considering 3.2 was released in 2004 and EOL in 2016... |
Hmm, this smells race-y, but on the server side. I don't think a client should have to be in the business of deciding which messages from the server are trustworthy. It's unfortunate in a way that Unreal 3.2.10 added support for Lines 916 to 925 in 51300a1
I'm playing with some possible resolutions locally. The trick will be figuring out when to selectively ignore what the WHO response says about privileges. |
I'm feeling pretty secure in at minimum leaving this until after 8.0.0 based on testing elsewhere (non-Unreal-3.2 IRCds).
This network CAP ACKed both A quick testing plugin ( isop.py codefrom __future__ import annotations
from sopel import plugin
@plugin.commands('isop')
def isop(bot, trigger):
if not trigger.group(3):
bot.reply("You dum-dum. I need a nick!")
return
is_not = 'is not'
if bot.channels[trigger.sender].privileges[trigger.group(3)] >= plugin.OP:
is_not = 'is'
bot.reply("{} {} a chanop.".format(trigger.group(3), is_not)) We might need to consider allowing the periodic |
To follow up on the discussion here while bringing it back to the actual bug report: Maybe One possible solution: queue MODE commands for later processing if a target exists in the pending WHO queue. Another, perhaps better, solution: Stop updating privileges from RPL_WHOREPLY / RPL_WHOSPCRPL. For both WHO and WHOX's For users already in the channel when Sopel joins, the initial RPL_NAMREPLY burst will give their current (or at least, highest) permissions. For a user joining after Sopel, the server has to send MODEs anyway. I think Sopel pulls privileges from WHO responses as a fallback for servers not supporting The theory is that if
Written, rewritten, and then deleted to focus on the bug: Ideas about reducing how often Sopel even sends WHO for a newly joined user it's already seen in another channel. |
Description
I recently encountered an issue where a channel op (+o) was not being treated as an op by the bot. Checking the raw log, I found this when they last joined the channel:
I'm not really sure how to handle this correctly, or if it's even Sopel's responsibility.
Reproduction steps
Run this test:
Expected behavior
bot.channels["#channel"].privileges["User"] = OP
Sopel version
Roughly 51300a1
Installation method
pip install
IRCd
Unreal3.2.10.6
The text was updated successfully, but these errors were encountered: