Add a CHANGELOG entry and record the arm the gate does not cover
The nowait fix is a user-visible behaviour change -- nowait now consumes socket bytes on a no-scheduler connection -- in a repo whose CHANGELOG says all notable changes are documented. Entered under Unreleased; the version bump is not mine to cut.
Also state in the test what it does not test. The guard expression is transport-independent, but the consequences are not: plain TCP keeps socket-ready? as a second no-park gate and TLS has none, so the TLS arm is the one with the larger blast radius if the flag is ever wrong, and it is the arm this test does not exercise. Verified by hand instead. A gate that quietly covers the safer half is worse than one that says which half it covers.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AbXvyDXoTUyqV1tb1fkeFa
CHANGELOG.md | 22 ++++++++++++++++++++++
test/integration/nowait-pump-client.sgl | 15 ++++++++++++++-
2 files changed, 36 insertions(+), 1 deletion(-)CHANGELOG.mdmodified
The format is based on [Keep a Changelog](https://keepachangelog.com/),and this project adheres to [Semantic Versioning](https://semver.org/).## [Unreleased]### Fixed- `ws-receive-nowait` now takes its single non-blocking socket read whenever the transport is actually non-blocking, instead of only when a scheduler is running. `ws-connect` sets non-blocking on `(or (current-scheduler) upgrade-timeout-ms)`, so a caller passing a bounded upgrade timeout with no scheduler previously got a non-blocking transport and a guard that denied the read: a pump calling `ws-receive-nowait` alone never issued a read at all and went permanently deaf, with the peer's frames left unread in the kernel receive queue. This is not TLS-specific and reproduces over plain `ws://`.### Changed- `ws-receive-nowait`'s docstring no longer claims it never touches the socket, and no longer prescribes pairing it with `socket-ready?` — advice that cannot be written for a `wss://` connection, because `socket-ready?` rejects TLS connections rather than resolving their descriptor the way `socket-select` does. The precondition for using it as a standalone pump (a scheduler or an `upgrade-timeout-ms` at connect time) is now stated explicitly.## [0.10.10] - 2026-09-03### Fixedtest/integration/nowait-pump-client.sglmodified
;;; the case that hid this defect.;;;;;; Nothing here is TLS-specific. The guard was never about TLS, and this runs;;; over plain `ws://` so it needs no certificate and no `openssl` on PATH.;;; over plain `ws://` so it needs no certificate and no `openssl` on PATH;;; (openssl is absent from the bare PATH on this estate's hosts, which is on;;; its own enough to keep a TLS fixture out of a gate).;;;;;; WHAT THIS TEST DOES NOT COVER, stated so nobody reads it as broader than it;;; is: the `wss://` arm. The guard expression is transport-independent, so the;;; logic under test is the same either way -- but the CONSEQUENCES are not;;; symmetric. On plain TCP, step 2 carries a second no-park gate;;; (`socket-ready?`); on TLS it does not, because `socket-ready?` raises on a;;; TLS connection, so the recorded non-blocking flag is the only thing keeping;;; that read from blocking. The TLS arm is therefore the one with the larger;;; blast radius if the flag is ever wrong, and it is the arm this test does;;; not exercise. It was verified by hand instead, against a local TLS server;;; and against the live Enclave, on 2026-09-04.(import (sigil core) (sigil time) (sigil websocket))