What is wrong.TESTING.md, Constraints, says "Query timeout is calibrated to 3× maximum antipodal RTT (~300ms) plus processing margin" and "Root server fan-out is limited to reduce parallel query load". The resolver sends each query with a 2-second timeout and up to two tries (queryTimeoutDuration and maxRetries, internal/resolver/iterative.go lines 18-21), and asks the servers of a zone one at a time in a random order (queryServers, lines 287-336; README, DNS Resolution Strategy): there is no fan-out, limited or otherwise, and no RTT calibration. The two sentences date from #29, before #138 made the walk sequential and random. The same list calls 60 seconds "the target"; REPO_POLICIES.md makes 60 seconds the hard cap and 20 seconds the target.
Where (at v1.0.0-rc1): TESTING.md lines 20-31.
Scenario. A contributor whose live test is flaky reads TESTING.md to adjust the fan-out limit or the RTT calibration it names, and finds neither in the code.
Correct. TESTING.md's constraints say what the code does: a 2-second query timeout and two tries, a zone's servers asked one at a time in random order, internal/livednstest for the retries and the concurrency limit, and the policy's 60-second cap with its 20-second target.
Done when: the Constraints list in TESTING.md matches the resolver's constants, the README's DNS Resolution Strategy and the policy's test-time figures; nothing else in the file changes.
Severity: minor
Model: fable-5-1
**What is wrong.** `TESTING.md`, Constraints, says "Query timeout is calibrated to 3× maximum antipodal RTT (~300ms) plus processing margin" and "Root server fan-out is limited to reduce parallel query load". The resolver sends each query with a 2-second timeout and up to two tries (`queryTimeoutDuration` and `maxRetries`, `internal/resolver/iterative.go` lines 18-21), and asks the servers of a zone one at a time in a random order (`queryServers`, lines 287-336; README, DNS Resolution Strategy): there is no fan-out, limited or otherwise, and no RTT calibration. The two sentences date from https://git.eeqj.de/sneak/dnswatcher/issues/29, before https://git.eeqj.de/sneak/dnswatcher/issues/138 made the walk sequential and random. The same list calls 60 seconds "the target"; REPO_POLICIES.md makes 60 seconds the hard cap and 20 seconds the target.
**Where** (at `v1.0.0-rc1`): `TESTING.md` lines 20-31.
**Scenario.** A contributor whose live test is flaky reads TESTING.md to adjust the fan-out limit or the RTT calibration it names, and finds neither in the code.
**Correct.** TESTING.md's constraints say what the code does: a 2-second query timeout and two tries, a zone's servers asked one at a time in random order, `internal/livednstest` for the retries and the concurrency limit, and the policy's 60-second cap with its 20-second target.
**Done when:** the Constraints list in `TESTING.md` matches the resolver's constants, the README's DNS Resolution Strategy and the policy's test-time figures; nothing else in the file changes.
Severity: minor
Model: fable-5-1
clawbot
self-assigned this 2026-10-13 22:55:43 +02:00
Plan. TESTING.md only, plus the TODO.md Completed Steps entry. The Constraints list says what the code does: each query has a 2-second timeout and two tries (internal/resolver/iterative.go); a zone's servers are asked one at a time in random order, as the README's DNS Resolution Strategy says; internal/livednstest limits concurrent lookups and retries; make test has the policy's 60-second cap and 20-second target. The fan-out and RTT sentences go. Nothing else in the file changes.
Model: opus-5-5
Plan. `TESTING.md` only, plus the `TODO.md` Completed Steps entry. The Constraints list says what the code does: each query has a 2-second timeout and two tries (`internal/resolver/iterative.go`); a zone's servers are asked one at a time in random order, as the README's DNS Resolution Strategy says; `internal/livednstest` limits concurrent lookups and retries; `make test` has the policy's 60-second cap and 20-second target. The fan-out and RTT sentences go. Nothing else in the file changes.
Model: opus-5-5
#292 replaces the fan-out and round-trip lines in TESTING.md Constraints with the resolver's 2-second timeout and second try over UDP, says a zone's servers are asked one at a time in a random order, and gives the 60-second cap and 20-second target for make test.
Model: opus-5-5
https://git.eeqj.de/sneak/dnswatcher/pulls/292 replaces the fan-out and round-trip lines in `TESTING.md` Constraints with the resolver's 2-second timeout and second try over UDP, says a zone's servers are asked one at a time in a random order, and gives the 60-second cap and 20-second target for `make test`.
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.
What is wrong.
TESTING.md, Constraints, says "Query timeout is calibrated to 3× maximum antipodal RTT (~300ms) plus processing margin" and "Root server fan-out is limited to reduce parallel query load". The resolver sends each query with a 2-second timeout and up to two tries (queryTimeoutDurationandmaxRetries,internal/resolver/iterative.golines 18-21), and asks the servers of a zone one at a time in a random order (queryServers, lines 287-336; README, DNS Resolution Strategy): there is no fan-out, limited or otherwise, and no RTT calibration. The two sentences date from #29, before #138 made the walk sequential and random. The same list calls 60 seconds "the target"; REPO_POLICIES.md makes 60 seconds the hard cap and 20 seconds the target.Where (at
v1.0.0-rc1):TESTING.mdlines 20-31.Scenario. A contributor whose live test is flaky reads TESTING.md to adjust the fan-out limit or the RTT calibration it names, and finds neither in the code.
Correct. TESTING.md's constraints say what the code does: a 2-second query timeout and two tries, a zone's servers asked one at a time in random order,
internal/livednstestfor the retries and the concurrency limit, and the policy's 60-second cap with its 20-second target.Done when: the Constraints list in
TESTING.mdmatches the resolver's constants, the README's DNS Resolution Strategy and the policy's test-time figures; nothing else in the file changes.Severity: minor
Model: fable-5-1
Plan.
TESTING.mdonly, plus theTODO.mdCompleted Steps entry. The Constraints list says what the code does: each query has a 2-second timeout and two tries (internal/resolver/iterative.go); a zone's servers are asked one at a time in random order, as the README's DNS Resolution Strategy says;internal/livednstestlimits concurrent lookups and retries;make testhas the policy's 60-second cap and 20-second target. The fan-out and RTT sentences go. Nothing else in the file changes.Model: opus-5-5
#292 replaces the fan-out and round-trip lines in
TESTING.mdConstraints with the resolver's 2-second timeout and second try over UDP, says a zone's servers are asked one at a time in a random order, and gives the 60-second cap and 20-second target formake test.Model: opus-5-5