The IRC listener keeps the connection's nick in Conn.nick (internal/ircserver/conn.go) and changes it only at registration and in the connection's own NICK handler (internal/ircserver/commands.go). When the same session changes its nick from another client, for example the web client sending NICK over the HTTP API, the database and every other client have the new nick, but the IRC connection keeps the old one.
The connection's handlers pass c.nick to the service as the sender. So after such a change, the PRIVMSG, NOTICE, JOIN, PART, TOPIC, KICK and INVITE it sends are stored and relayed under a nick the session no longer holds, and which another user may since have taken; a later NICK from the connection announces the wrong old nick; and the server's numerics are addressed to the old nick. Read from the code on d539b4c and #183, which makes the connection receive that NICK line.
Fix, recommended: when the relay (internal/ircserver/relay.go) delivers a NICK change whose old nick is exactly the connection's nick (nicks are unique and compared by exact case, so it is the connection's own session), it sets the connection's nick to the new one, under c.mu, before writing the line. Keep it that small. If a plainer fix makes the connection always use the session's current nick, take it and say why in the PR body.
Definition of done
A session with an HTTP API client and an IRC listener connection: after the HTTP client changes the nick, a PRIVMSG and a JOIN made from the IRC connection reach other users under the new nick, and a NICK made from the IRC connection announces the new nick as the old one.
A test in internal/ircserver for item 1 that fails on the old code.
One reviewed PR against next, cut after #183 has landed.
Model: opus-5-5
The IRC listener keeps the connection's nick in `Conn.nick` (`internal/ircserver/conn.go`) and changes it only at registration and in the connection's own `NICK` handler (`internal/ircserver/commands.go`). When the same session changes its nick from another client, for example the web client sending `NICK` over the HTTP API, the database and every other client have the new nick, but the IRC connection keeps the old one.
The connection's handlers pass `c.nick` to the service as the sender. So after such a change, the PRIVMSG, NOTICE, JOIN, PART, TOPIC, KICK and INVITE it sends are stored and relayed under a nick the session no longer holds, and which another user may since have taken; a later `NICK` from the connection announces the wrong old nick; and the server's numerics are addressed to the old nick. Read from the code on `d539b4c` and https://git.eeqj.de/sneak/neoirc/pulls/183, which makes the connection receive that `NICK` line.
Fix, recommended: when the relay (`internal/ircserver/relay.go`) delivers a `NICK` change whose old nick is exactly the connection's nick (nicks are unique and compared by exact case, so it is the connection's own session), it sets the connection's nick to the new one, under `c.mu`, before writing the line. Keep it that small. If a plainer fix makes the connection always use the session's current nick, take it and say why in the PR body.
## Definition of done
1. A session with an HTTP API client and an IRC listener connection: after the HTTP client changes the nick, a PRIVMSG and a JOIN made from the IRC connection reach other users under the new nick, and a `NICK` made from the IRC connection announces the new nick as the old one.
2. A test in `internal/ircserver` for item 1 that fails on the old code.
3. One reviewed PR against `next`, cut after https://git.eeqj.de/sneak/neoirc/pulls/183 has landed.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The IRC listener keeps the connection's nick in
Conn.nick(internal/ircserver/conn.go) and changes it only at registration and in the connection's ownNICKhandler (internal/ircserver/commands.go). When the same session changes its nick from another client, for example the web client sendingNICKover the HTTP API, the database and every other client have the new nick, but the IRC connection keeps the old one.The connection's handlers pass
c.nickto the service as the sender. So after such a change, the PRIVMSG, NOTICE, JOIN, PART, TOPIC, KICK and INVITE it sends are stored and relayed under a nick the session no longer holds, and which another user may since have taken; a laterNICKfrom the connection announces the wrong old nick; and the server's numerics are addressed to the old nick. Read from the code ond539b4cand #183, which makes the connection receive thatNICKline.Fix, recommended: when the relay (
internal/ircserver/relay.go) delivers aNICKchange whose old nick is exactly the connection's nick (nicks are unique and compared by exact case, so it is the connection's own session), it sets the connection's nick to the new one, underc.mu, before writing the line. Keep it that small. If a plainer fix makes the connection always use the session's current nick, take it and say why in the PR body.Definition of done
NICKmade from the IRC connection announces the new nick as the old one.internal/ircserverfor item 1 that fails on the old code.next, cut after #183 has landed.Model: opus-5-5