UHNAMES Race Condition

[half-duplex]

Description

When Sopel joins a server that supports UHNAMES but not the userhost-in-names CAP, it sends PROTOCTL UHNAMES to accomplish the same goal.

In my testing, this results in:

>> CAP LS 302
>> NICK Sopel
>> USER ...
<< 001 ...
>> JOIN #test
<< 005 [...] UHNAMES
>> PROTOCTL UHNAMES
<< JOIN #test
<< 353 Sopel = #test :@Op Sopel

Followed by an exception (expected 2 to unpack, got 1) on coretasks.py:524

Sending PROTOCTL UHNAMES before the JOIN seems to work.

The same problem may exist with the CAP, if not in practice, than in theory.

Previously: #2102

Reproduction steps

1. Find a server with UHNAMES but no userhost-in-names
2. Configure Sopel to connect to it and join a channel
3. Start sopel
4. Note exception

Expected behavior

Joins without exception

Environment

• Sopel .version: 36b7c2f
• Sopel installed via: pip
• Python version: 3.9.2
• Operating system: Debian 10
• IRCd /version: InspIRCd 2

Notes

@dgw broke it

[Exirel]

I can see a quick fix, that would probably be a safe fix as well: try/catch.

[dgw]

The best solution would simply prevent sending any JOINs until after 005 has been processed.

I would love to just move a bunch of startup tasks from 001 to 251, but unfortunately the latter is no longer required. We could move joining channels to a new handler that triggers on 376 (RPL_ENDOFMOTD) or 422 (ERR_NOMOTD), since the server "MUST" send either the MOTD or 422 after 001-005. We already constrain ISUPPORT handling to happen on the main thread, so that should block until after PROTOCTL UHNAMES has been sent, after which it will be fine to send JOINs. (Can also try/except the line that currently errors, for maximum safety.)

The advantage of triggering JOINs and such on 001 is that it's existed in the spec for ages. As unlikely as it would be to encounter an IRCd that doesn't send 005, or doesn't send the MOTD automatically after registration, it's far more unlikely to find a server that doesn't send 001—that would completely break the protocol, as I understand it.

As an aside, I have no idea why this rule exists on the 005 handler. It shouldn't be necessary. Though I guess it's a guard against super outdated IRCds that still use 005 as RPL_BOUNCE, per RFC 2812.

[Exirel]

We could move joining channels to a new handler that triggers on 376 (RPL_ENDOFMOTD) or 422 (ERR_NOMOTD), since the server "MUST" send either the MOTD or 422 after 001-005.

That shouldn't be too much of a trouble, right? Right... I'll try.

[Exirel]

So, hm... you're not going to believe that: it's stupidly simple. All I have to do is move a portion of the code into its own plugin callable in coretasks. Everything else is just about managing the automated tests.

[Exirel]

@half-duplex I invite you to take a look at #2321 as it should fix this issue, however I don't have a server to test the PR against.