Allow updating an ISUPPORT token. #585
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently if a server makes a configuration (or entire IRCd) change which affects any ISUPPORT (005) tokens, the entire core needs to be restarted in order to internally reflect these changes. With this change, upon the receipt of an ISUPPORT message, if any tokens now differ from our internal state, they will be updated. The best way to update these is still a reconnect of that server, which is far better restarting the entire core.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In Brief
support(orISUPPORT) tokens for a network when they change.Impact
Rationale
Currently, if a network changes their configuration in such a way that one or more of their ISUPPORT tokens changes, the core must be restarted in order for it to see these updated tokens. Obviously this is a non-ideal way to handle a change in one network. Allowing the core to update its internal state when a change occurs removes the need for a restart. That said, not all IRCds will send an updated ISUPPORT message for all changes, or at all. A manual
/VERSIONor reconnect may still be required. This is still better than a core restart.Recent example case:
Freenode recently did a big switch of IRCd and services software, resulting in at least a few changes to the ISUPPORT tokens. Two of the notable token changes were
PREFIXandSTATUSMSG, as they added two prefixes (also added to statusmsg). The more common prefix of these two beinghalfop (h | %). After disconnecting from 'old freenode' and connecting to 'new freenode', I noticed this change in the ISUPPORT message and kept an eye on channels for the use of them. Joining a channel with halfops in it or running/nameson an existing channel would show halfops in the nick list as%nickunder User(s) instead ofnickunder Half-Op(s). Un-tested/noticed, this likely would have messed up status message matching as well, since%would not have been known as a character to match. A core restart was required in order to clear/update the internal state.Testing
Using the above example as a before test case, I ran a test with my InspIRCd v3 testnet. I removed halfop from the configuration, connected Quassel and joined a channel, and re-added halfop to the configuration. This still resulted in the possibility of seeing a halfop as
%nickin the User(s) section before a manual/versionor reconnect is done. Running/versionand then updating the channel with/namesplaced the user in the correct Half-Op(s) section, leaving behind a%nickin the User(s) section yet. This is not surprising as the core still thought of them as separate users with the prefix character change. The same can happen in the before case with a halfop being de-halfop'ed and so forth. A reconnect to the network cleared everything up.