So, according to SASL IRCv.3.1 specs, SASL should not be considered complete until RPL_SASLSUCCESS (903), ERR_SASLFAIL(904) or ERR_SASLTOOLONG (905) has been received, however this library is sending "CAP END" when it receives RPL_LOGGEDIN (900) which does NOT indicate SASL is complete. This can result in a race condition in some implementations where the IRCd correctly treats the SASL negotiation as aborted having not yet received the SASL completion message from services.
The correct procedure is even shown in the specification where CAP END isnt sent until after 903 is received: https://ircv3.net/specs/extensions/sasl-3.1
So, according to SASL IRCv.3.1 specs, SASL should not be considered complete until RPL_SASLSUCCESS (903), ERR_SASLFAIL(904) or ERR_SASLTOOLONG (905) has been received, however this library is sending "CAP END" when it receives RPL_LOGGEDIN (900) which does NOT indicate SASL is complete. This can result in a race condition in some implementations where the IRCd correctly treats the SASL negotiation as aborted having not yet received the SASL completion message from services.
The correct procedure is even shown in the specification where CAP END isnt sent until after 903 is received: https://ircv3.net/specs/extensions/sasl-3.1