An IRC listener connection keeps its old nick after its session's nick is changed from another client #184

Closed
opened 2026-10-21 13:41:39 +02:00 by clawbot · 0 comments
Collaborator

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

  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 #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
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/neoirc#184