[go-while]

Bug found by the new test, fixed here (21e5d48, reworked in fa0d23f):
with the session's end now measured without /proc too, FreeBSD CI failed:
OVER 6.088 s, XOVER 6.044 s after the request, bound 4.5 s (ClientTimeout
3): two send timeouts. When SO_SNDTIMEO runs out after send() has taken
part of the data, the kernel returns that part instead of EAGAIN (FreeBSD
and Linux alike: on Linux 1774 of 4096 bytes after 1 s, then EAGAIN after
another second), and sockstreambuf::sync() sent the rest with a second
wait. Now, after a short send, the rest goes out only if the socket
becomes writable (poll) within what is left of the socket's send timeout,
counted from the start of the send call that returned short (read with
getsockopt: a client's is set on its socket, not through set_io_timeout);
otherwise the write fails like a failed send. A short count from a signal
therefore never ends the write early, and the timeout never runs twice.
Not during a reply deadline (non-blocking socket): unchanged. (21e5d48
used a 90 %-of-the-timeout guess instead; Terra pointed out that it
could cut a write short after a late signal and counted EINTR retries.)

New check in cReplyBudget: loopback TCP with a small window, SO_SNDTIMEO
1 s, a peer that reads nothing; the write must fail within 1.5 s.
main's sockstream: 2.06-2.07 s, FAIL 3/3; with the fix 1.00-1.06 s, pass.
Linux: the stall/timeout e2e tests pass; full suite passed on 21e5d48,
running again on fa0d23f. FreeBSD CI must now pass.

Old: client A asked for OVER/XOVER 1-40000 (served from the fake
upstream, which runs in the race-instrumented test process) and stopped
reading; after 2 s client B's GROUP and ARTICLE 39999 had to be
answered within 20 s. Nothing checked when A's session ended. Since
#274 writes the records with the group's lock released, B is served
even when A's session stays blocked in send() for good, so the test no
longer saw what 3cefac9 (ClientTimeout for each write) and 763126c
(drop the buffer after a failed send) fixed.

New, as #369 did for the TLS test: a first client fills the cache, so
A's reply comes from the spool and its socket fills at once; A's
session pid is the daemon's only child, and a goroutine records when
it is gone, measured from just before A's request (through
daemonChildren from #369: /proc, or pgrep -P without /proc; no t.Fatal
from the goroutine, and it stops with the test). The session must be
gone within 1.5 ClientTimeouts (4.5 s); in a file-log build "can't be
written to, session ended" must be logged too, as a check of why it
ended (not of when: that line comes at the first failed write, 3 s
before the end with 763126c reverted). B's part is unchanged. Skips only
where neither /proc nor pgrep exists.

Measured (12 cores, ClientTimeout 3): the session ended 3.04-3.10 s
after the request (5 runs x OVER/XOVER), 3.27-3.37 s with -race; all
pass.

Mutants (scratch only):

1. 763126c reverted (sockstream.cc: the buffer kept after a failed
   send): the new test fails, OVER and XOVER:
   stalled reader's session 2064767 ended 6.035s after the request,
   want within 4.5s
2. no SO_SNDTIMEO on the client's output (set_socket_timeouts, the
   core of 3cefac9): the new test fails:
   stalled reader's session 2065805 still running 14.501s after the
   request, want it gone within 4.5s
   The test from origin/main passes against both mutants.

Without /proc (scratch change hiding it, pgrep path): main 3.10-3.14 s,
pass; 763126c reverted 6.14-6.16 s, fails. (An earlier head used the
log line as the end without /proc, which didn't check the bound there:
Terra's finding.)

Part of the review of weakened tests that go-while asked for. Shown to fail with the guarded defect (scratch mutant; not committed).

NEWS: changes/fix-stalled-reader-test-from-spool.md.

🤖 Generated with Claude Code