internal/ircserver: Disconnect doc comment understates the worst-case socket close delay #103

New Issue

2026-09-04T08:49:24+02:00

clawbot commented

2026-09-04 08:49:24 +02:00

Non-blocking docs-precision finding from the round-7 review of #96 (which PASSed and is merge-ready). Filing separately rather than blocking that PR.

Conn.Disconnect's doc comment at internal/ircserver/conn.go:126 says:

Disconnect therefore returns as soon as the victim is marked closed; the socket is closed shortly afterwards regardless of whether the notification could be delivered.

"Shortly afterwards" is not bounded by the 2s deadline alone. The detached notify-and-close goroutine must first acquire the victim's writeMu. If the victim's relay goroutine already holds it under the 30s writeTimeout, the goroutine waits for the mutex before its own 2s window starts — roughly 34s worst case.

This does not affect the killer, which is the property the B3 fix and TestDisconnectDoesNotBlockOnUnresponsiveVictim actually guarantee; the killer still returns promptly. The behaviour is correct, only the comment is imprecise.

Suggested fix: state the real bound in the comment — the close happens within writeTimeout + 2s of the call, and the 2s deadline covers only the write, not the wait for writeMu.

Docs only; agent-eligible if you want to label it.

Non-blocking docs-precision finding from the round-7 review of #96 (which PASSed and is merge-ready). Filing separately rather than blocking that PR. `Conn.Disconnect`'s doc comment at `internal/ircserver/conn.go:126` says: > Disconnect therefore returns as soon as the victim is marked closed; the socket is closed **shortly afterwards** regardless of whether the notification could be delivered. "Shortly afterwards" is not bounded by the 2s deadline alone. The detached notify-and-close goroutine must first acquire the victim's `writeMu`. If the victim's relay goroutine already holds it under the 30s `writeTimeout`, the goroutine waits for the mutex *before* its own 2s window starts — roughly 34s worst case. This does **not** affect the killer, which is the property the B3 fix and `TestDisconnectDoesNotBlockOnUnresponsiveVictim` actually guarantee; the killer still returns promptly. The behaviour is correct, only the comment is imprecise. Suggested fix: state the real bound in the comment — the close happens within `writeTimeout + 2s` of the call, and the 2s deadline covers only the write, not the wait for `writeMu`. Docs only; agent-eligible if you want to label it.

~~clawbot referenced this issue 2026-09-04 08:49:39 +02:00~~

feat: implement Tier 3 utility IRC commands (USERHOST, VERSION, ADMIN, INFO, TIME, KILL, WALLOPS) (closes #87) #96

clawbot commented

2026-09-05 11:32:53 +02:00

Closed at sneak's instruction, 2026-09-05: this was opened by an agent running on another machine outside the managed fleet, under superseded rules. Reopen if the content is wanted.

Model: fable-5-1

Closed at sneak's instruction, 2026-09-05: this was opened by an agent running on another machine outside the managed fleet, under superseded rules. Reopen if the content is wanted. Model: fable-5-1

clawbot closed this issue

2026-09-05 11:32:53 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/neoirc#103