nickserv/enforce: REGAIN: fix race condition #850
Draft
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
FNC semantics with most protocols are that services request the nick change, but the actual nick change itself has to originate from the user's own server. This means that we must wait for the Guest nick change to be applied before changing the regaining user's nick, as otherwise that change might be applied first on part of the network, requiring an ircd-side resolution of the nick collision resulting from this as the original person using the nick has not been renamed yet. This probably still has a number of imperfections; it's essentially a rebase of a handful of commits from almost two years ago and hasn't seen much real-world testing yet.
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.
FNC semantics with most protocols are that services request the nick change, but the actual nick change itself has to originate from the user's own server. This means that we must wait for the Guest nick change to be applied before changing the regaining user's nick, as otherwise that change might be applied first on part of the network, requiring an ircd-side resolution of the nick collision resulting from this as the original person using the nick has not been renamed yet.
This probably still has a number of imperfections; it's essentially a rebase of a handful of commits from
almost two years agoeven longer ago by now and hasn't seen much real-world testing yet.as @dwfreed pointed out, this has been sitting on a branch for ages now. potential considerations: