The sanitized operational line promised for a header/request timeout was never actually emitted. Driving a real slow-header and slow-body connection through a real socket against the pinned Node 24 runtime shows the general server 'timeout' event never fires for headersTimeout/requestTimeout — that event belongs to server.setTimeout()'s idle-socket timer, which this server never arms. Both surface as 'clientError' carrying err.code === "ERR_HTTP_REQUEST_TIMEOUT". bindServer now observes 'clientError'. Because registering any such listener suppresses Node's own default response entirely, the handler reproduces that default byte-for-byte — 408 for a timeout, 431 for a header overflow, 400 otherwise — writing it only when the socket is still writable and no response has already begun, then destroying the socket exactly as Node would. Exactly one fixed sanitized line is logged per event, never the caught error's own message, which for a parse failure derives from attacker-controlled input. Proof moves to the real transport boundary: raw-socket scenarios assert the exact response bytes, exactly one status line, socket closure, handler non-invocation, and exactly one sanitized log for a slow-header connection, a slow-body connection, a malformed request line, and an oversized header block. The prior unit test, which manually emitted 'timeout', is removed as misleading. Co-Authored-By: Claude Opus 5 <[email protected]>
Architecture decision records
ADRs capture durable choices that affect more than one package or phase.
- Filenames use a four-digit sequence followed by a short kebab-case title.
- Status is
Proposed,Accepted,Superseded, orRejected. - Accepted ADRs are immutable except for status and cross-reference corrections.
- A changed decision receives a new ADR that links to and supersedes the old one.
Index
- 0001: Four-layer platform boundary — Accepted
- 0002: pnpm workspace and strict TypeScript — Accepted
- 0003: Development infrastructure — Accepted
- 0004: Replace unmaintained MinIO baseline — Accepted
- 0005: Static module manifests and atomic discovery — Superseded
- 0006: Versioned capabilities and compiled module runtime — Accepted
- 0007: Module-owned Drizzle schemas and table isolation — Accepted
- 0008: Module-owned migration contracts and offline validation — Accepted
- 0009: Transactional module migration execution — Accepted
- 0010: Core identity architecture and Better Auth adoption — Accepted
- 0011: Identity HTTP transport and public enrollment policy — Accepted
- 0012: Production-equivalent identity origin/CSRF protection under test — Accepted
- 0013: Core authorization, permission registry, and platform-owner bootstrap — Accepted
- 0014: Module permission declarations and platform permission registry — Accepted
- 0015: Static module HTTP routing and production runtime lifecycle — Accepted
- 0016: Module database access — Accepted
- 0017: Public request perimeter hardening — client address, signup gating, body limits, timeouts — Accepted