Repository navigation
e2e: TestSpoolDiskFullDaemon bounds the replies on the full disk again - #373
Merged
Merged
Conversation
Old (#83): ClientTimeout 600, and every reply and dial had a 180 s deadline, so a lock left held (or any stall) of up to about 170 s passed. The reason: client 2's last command, XOVER 19990-20000, came from the chunk 10000-19999, which couldn't be kept on the full disk, so NewsCache fetched 10000 records twice from the fake upstream, which runs in the race-instrumented test process: 20-21.5 s under -race (3 s without), measured inside client 2's session while client 1 idled, which on a busy machine passed the default ClientTimeout. New: the group has 20010 articles and client 2 asks for XOVER 20000-20010, a last chunk of 11 records that can't be kept either (the log still shows "updating the overview database failed" during client 2's session, and the records are passed on). Client 1's first commands, which fill the cache from the fake upstream, are setup and keep the 180 s hang guard. Everything after, on the full disk (client 1's LIST, client 2's dial and six commands, client 1's two commands afterwards), must be answered completely within 5 s, with the default ClientTimeout 60: client 1 stays connected, so a lock it left held blocks client 2 for good. Measured (12 cores): the commands on the full disk took at most 56 ms (5 runs) and 137 ms with -race (5 runs); all pass. A -race subtest now takes about 20 s instead of 40 s. Mutant (scratch only): ~NVLock() skips release() while an exception unwinds (std::uncaught_exceptions() > 0), i.e. the lock leak e9ac5bd fixed. The new test fails in both subtests after 5 s: client 2: greeting: read tcp 127.0.0.1:42550->127.0.0.1:40337: i/o timeout The test from origin/main fails too, but only after 184 s. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
An error reply (a 411 GROUP, then 412 for XOVER and ARTICLE) comes at once: the time bound passed without any data being sent, and only ARTICLE and the record count of a 224 XOVER were checked. Now LIST must answer 215, GROUP 211, XOVER 224 and ARTICLE 220. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or 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
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.
Old (#83): ClientTimeout 600, and every reply and dial had a 180 s
deadline, so a lock left held (or any stall) of up to about 170 s
passed. The reason: client 2's last command, XOVER 19990-20000, came
from the chunk 10000-19999, which couldn't be kept on the full disk,
so NewsCache fetched 10000 records twice from the fake upstream, which
runs in the race-instrumented test process: 20-21.5 s under -race
(3 s without), measured inside client 2's session while client 1
idled, which on a busy machine passed the default ClientTimeout.
New: the group has 20010 articles and client 2 asks for XOVER
20000-20010, a last chunk of 11 records that can't be kept either
(the log still shows "updating the overview database failed" during
client 2's session, and the records are passed on). Client 1's first
commands, which fill the cache from the fake upstream, are setup and
keep the 180 s hang guard. Everything after, on the full disk (client
1's LIST, client 2's dial and six commands, client 1's two commands
afterwards), must be answered completely within 5 s, with the default
ClientTimeout 60: client 1 stays connected, so a lock it left held
blocks client 2 for good.
Measured (12 cores): the commands on the full disk took at most 56 ms
(5 runs) and 137 ms with -race (5 runs); all pass. A -race subtest now
takes about 20 s instead of 40 s.
Mutant (scratch only): ~NVLock() skips release() while an exception
unwinds (std::uncaught_exceptions() > 0), i.e. the lock leak e9ac5bd
fixed. The new test fails in both subtests after 5 s:
client 2: greeting: read tcp 127.0.0.1:42550->127.0.0.1:40337: i/o
timeout
The test from origin/main fails too, but only after 184 s.
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-spool-diskfull-test-bounds.md.Success codes (1a7e47b): each command must now answer its success code (LIST 215, GROUP 211, XOVER 224, ARTICLE 220). Before, only ARTICLE and the record count of a 224 XOVER were checked, so an error reply, which comes at once, passed the 5 s bound without any data being sent. Control: with client 2 sent to a missing group (scratch change, not committed), the test fails on the 411 GROUP and the 412 XOVERs; the old helper reported only the ARTICLE. Passed normally (13.7 s) and with -race (52 s).
🤖 Generated with Claude Code