Closes #70. `validator.opentechevents.org` called `https://eventos.wiki/events.json` — a registered adopter's feed — `unreachable`, while the registration bot that links here told that publisher the same feed was valid. Measured: the feed answers 200 with ~554 KB in 23.6-51 s, consistently. Only the clock was wrong. **60 s, for the hop and the chain alike.** Not a number chosen here: the spec repo's daily health check and its adopter-registration bot both fetch with 60 s and retries, each after this same false negative was removed from it (spec PRs #43 and #46). The issue floats 20-30 s per hop, but the feed's slow runs reach 51 s, so anything under 60 reopens the bug on a slower day. The normal case is one hop and must be able to spend the whole budget; a redirect chain still cannot multiply the wait, since each hop takes only what the chain has left. **A connect deadline that actually exists.** Raising the number alone replaces one false negative with its mirror image: measured against the runtime, a live host with a filtered port spent the entire 60 s and came back reading "slow". `fetch` cannot separate the handshake from the bytes — one `AbortSignal` covers both — so each hop now opens a bare TCP connection first, under its own 8 s budget (`src/tcp-probe.ts`). The discrimination is stark: the adopter feed accepts a connection in 0.1 s and answers in 23.6 s, while nothing-is-listening is settled in 8. That case gets `no-connection`, never the word "slow". The probe **fails open**: anything other than a clean "nothing accepted a connection in time" is inconclusive and the fetch proceeds as if it had not run. It may shorten a hopeless wait; it must never invent a failure for a feed that would have loaded. Two findings from probing the real runtime, neither visible to a fake: `connect()` to an IP literal does not behave (an IPv4 literal timed out at 6 s where the hostname opened in 25 ms; an IPv6 literal is refused outright), so the probe connects by hostname, after the SSRF checks and reaching nothing they do not already permit; and `close()` on a socket that never opened is never awaited, because it may not settle and would hang the request past the budget the probe exists to impose. **One retry, never for a timeout.** A reset connection or a 502 from a shared host is not a verdict about a feed, so a hop gets a second attempt after a transport error or a 429/5xx — failures that arrive fast. 4xx is deterministic and is not asked twice. Deliberately narrower than the other two tools': they run unattended, while here somebody is watching a spinner, and having waited the full budget once, waiting it again ends in "slow" 60 s later anyway. **Slow and dead must not read alike**, which is why raising the clock is not the whole fix. The timeout message says the origin is slow and the feed is not invalid; `/badge` grows a `slow` state, apart from `unreachable`, because that image sits in a publisher's README. And #105's transport section still reports the 23.6 s: the feed now validates *and* is told what is wrong with how it is served. The badge caption on the page listed only the old vocabulary and would have lied about the new state. Verified against a local Worker, since this app's worst failures are invisible to vitest: | Case | Before | After | Badge | | --- | --- | --- | --- | | Valid, slow adopter feed | `timeout` @5.2 s | 200, 568 KB @23.7 s | `valid` | | Nothing listening on the port | 60.0 s, "slow" | `no-connection` @8.2 s | `unreachable` | | Hostname does not resolve | — | 0.12 s | `unreachable` | | Answers nothing past 60 s | `unreachable` | `slow`, TTL 300 s | `slow` | The page was driven in a browser for both the slow feed (valid, with the 23.1 s finding) and the unreachable one. The retry and `body.cancel()` paths ran live too: a 503 took 1.01 s against a 0.18 s baseline. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Commits

Commits on Nov 4, 2026

fix(validator): wait as long as the ecosystem does, and tell slow from dead