2 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
clawbot	6b0fdc477a	test: restore transport-failure coverage with loopback nameservers ... The DNS-mock removal deleted TestQueryNameserverIP_Timeout and left a comment in its place, so the resolver's StatusTimeout / StatusError classification branch went untested. The stated obstacle was that a query to a black-holed RFC 5737 address comes back StatusOK, because the build environment transparently intercepts UDP/53 and answers it locally. That is a property of that environment, not of the resolver, and it only rules out choosing a remote address. internal/resolver/transport_test.go binds real nameservers on 127.0.0.1 instead and aims the query at them: one silent on A queries and answering every other type (StatusTimeout), one answering SERVFAIL (StatusError), and one address with nothing listening, which is refused rather than dropped and so classifies as NoData. This is not a mock — no DNSClient is substituted. The resolver dials a real socket, writes a real query with the real miekg/dns client, and applies its real deadline and real classification logic to what comes back. Substituting the client is what TESTING.md bans; choosing the server is not, and the resolver is aimed at a caller-chosen nameserver in production too. queryDNS now dials a nameserver address that already carries a port as written, defaulting to 53 only for a bare address. That is what makes a nameserver on any other port reachable, on loopback or otherwise. Silence on one record type rather than all eight keeps the timeout test to two query timeouts (4s) instead of sixteen (32s), and it is asserted: the test fails if it ever costs more than 8s. The watcher's assertStatePopulated and TestDomainPortAndTLSChecks asserted only that hostname, port and certificate state were non-empty, plus non-zero checker call counts. Neither was vacuous, but neither would have caught the watcher resolving the wrong addresses. The port and TLS test doubles now record their arguments, and both tests assert that the state keys and the arguments the checkers were actually called with match the addresses live DNS returned — exactly those, no more and no fewer. Verified by mutation: making the watcher drop all but one resolved address fails both tests, and it passed both of them before. TESTING.md records why a loopback nameserver is not a mock, so the new tests are not mistaken for a violation of the rule they respect.	2026-09-03 22:58:01 +00:00
clawbot	62dec447e3	test: bound watcher live DNS and serialise packages after rebase ... Rebasing this branch onto next surfaced two failures that the branch did not have in isolation. Both come from the change this PR makes: the watcher package now queries live DNS, and it is the second package to do so. Burst fan-out in the watcher package. All 13 watcher tests are parallel and each runs a full iterative resolution, so they hit the same root servers in the same instant and get rate-limited. This is exactly the pathology internal/resolver/livedns_test.go was written to prevent (9cb2c2b); that gate is package-scoped and cannot reach into this package's test binary, so liveWatcherGate is its counterpart here, acquired in newTestWatcher and released when the test ends. Cross-package oversubscription. Go runs package binaries in parallel, so with both live-DNS packages in flight their gates sum rather than hold. The excess is rate-limited and the resolver's 8s per-attempt deadlines expire, failing ResolveIPAddresses tests this branch never touched. script/test now passes -p 1 so each gate is authoritative while its package runs. Serialising is also net faster here, because the retries it removes cost more than the lost parallelism: resolver 16-22s (was 30-36s under contention), watcher 12-13s (was 27-37s), whole suite 39-46s against the 60s cap and the 90s -timeout backstop. TestQueryNameserverIP_UnreachableServer is dropped rather than fixed. It asserted that a query to an RFC 5737 documentation address comes back non-OK with no records, which does not hold in the build environment: that network transparently intercepts all UDP/53 traffic regardless of destination and answers it locally, so the query returns StatusOK with 9 real records for example.com. Verified directly with dig @192.0.2.1 inside the build network. The mock DNSClient that used to force this classification is what this PR removes, and a live substitute would only be testing the sandbox's network behaviour, so the coverage gap is recorded in a comment where the test was. Verified: three consecutive `docker build .` runs green, after three consecutive failures without these changes.	2026-09-03 17:01:08 +00:00