middleware/websocket tests: the native-engine start helper never reads Start's error, so a failed start is reported as a 30 s "server not ready within timeout"

[FumingPower3925]

Summary

middleware/websocket's engine test helper drops the server's start error. startNativeServerWithHandle (engine_linux_test.go:63 at main 9f4d89b) runs s.StartWithListenerAndContext in a goroutine and sends its error to done. It then calls waitForReady (engine_test.go:17), which polls s.Addr() and a dial for 30 s and fails with server not ready within timeout. It never reads done. So when a native engine fails to start, the test burns 30 s and reports a generic timeout instead of the real error. The real error could be io_uring_setup ENOMEM at the CI shape's 8 MiB memlock, or a refused bind.

Seen

In the #633 reproducer matrix (PR #671's lane, round cover633-07-head), io_uring/multishot_recv logged the RLIMIT_MEMLOCK worker cap, never logged that it was listening, and failed after 30.01 s with server not ready within timeout. The log cannot tell whether Start failed or hung. The same file is on main and on #671, so #671 did not cause it.

Why it matters for v1.6.0

The CI shape is a one-worker io_uring ring at ulimit -l 8192, and the WebSocket suites run there. A start failure (a real regression, or an environment ENOMEM that should be a skip) is misreported as a readiness timeout. It is then easy to misfile as a flake of the #633/#652 stall family, which these same suites are used to measure. An oracle that discards an error blocks every diagnosis.

Fix direction

Make waitForReady (or the helper) select on done while polling, and fail with Start's error as soon as it returns. If the start error is the known environment case (io_uring unavailable, or ENOMEM below the documented memlock floor), skip with that reason, but only where the suite's CI step forbids silent skips, so it cannot become a silent hole (#684). Apply the same pattern to any other helper that starts a server in a goroutine and then only polls for readiness; grep for waitForReady( and Start.*Context( in _test.go.

Related: #633, #652, #684, #671.

[FumingPower3925]

PR #730 fixes the case this issue reports: middleware/websocket's waitForReady, and its copy in middleware/static, now fail as soon as Start returns, with Start's error. PR #730 no longer closes this issue (it says Refs #706), because the last step of the fix direction is not done: the same pattern in every other helper that starts a server in a goroutine and then waits for it.

Audit of main at 2776d4c, from the issue's own grep (waitForReady( and Start.*Context( in _test.go) plus StartWithListener( called in a goroutine. Line numbers are the go func() that runs Start.

Waits for the server without reading Start's error while it waits. A failed start costs the whole wait and its cause is lost, or the test goes on against no server:

site	engine	wait	what a failed start does
middleware/integration_chain_engine_test.go:46 (liveEngineServer)	epoll	5 s	fails with server not ready within 5s; done is read only in t.Cleanup
middleware/sse/sse_disconnect_linux_test.go:108 (startSSEServer)	epoll, io_uring	30 s	reports the error, but only after the 30 s deadline
middleware/websocket/server_close_drain_linux_test.go:309 (tag celeris_closeprobe)	native	30 s	fails with server not ready within 30s; serverDone is never read
async_promote_integration_linux_test.go:34	epoll	5 s	_ = s.StartWithListener(ln) drops the error, and the readiness GET has no timeout
test/drivercmp/redis/integrated_async_test.go:38	parameter	5 s	done is never read; srv.Addr().String() then dereferences nil
middleware/integration_chain_test.go:38 (liveServer)	std	2 s	dials ln.Addr()
middleware/pre_routing_order_test.go:32 (startTestServer)	std	2 s	dials ln.Addr()
server_async_test.go:46 (startMixedAsyncServer)	std	5 s	_ = s.StartWithListener(ln); GETs with no timeout, and returns whether or not the server answered
server_shutdown_test.go:96 (TestStartAfterShutdown)	std	2 s	dials ln.Addr(), and goes on either way
server_shutdown_test.go:37 (TestServerShutdownDrainsInFlight)	std	2 s	fails with handler did not start in time
adaptive_settle_reopen_test.go:267 (TestRouteAdaptive_NoReopenerWhenEngineCreationFails, discriminator)	std	10 s	fails with discriminator: a server that started must have the re-opener running
engine/std/sse_shutdown_test.go:73	std	5 s	dials ln.Addr(); serverDone is never read

A helper that dials the listener it passed in cannot tell a failed start from a ready server: a Start that fails leaves that listener open, and the kernel completes the handshake into its backlog. Such a helper needs to read Start's error before each probe and to probe something only a started server answers (s.Addr(), or a request with a short timeout, as start_shutdown_return_linux_test.go's waitReady does).

Read the error once, after a fixed 500 ms sleep. A start that fails later than that is missed: engine/epoll/detach_inline_regression_linux_test.go:122, engine/epoll/rdhup_detached_linux_test.go:51, middleware/sse/sse_engine_linux_test.go:82, middleware/websocket/websocket_engine_linux_test.go:72, middleware/websocket/detached_count_window_linux_test.go:169, middleware/websocket/wsrst_torture_linux_test.go:78.

Already read the error while they wait: adaptive_settled_retime_linux_test.go, server_prebound_listener_linux_test.go, start_shutdown_return_linux_test.go (waitReady), middleware/session/engine_roundtrip_test.go, test/drivercmp/postgres/integrated_test.go, test/drivercmp/redis/integrated_test.go, test/integration/*, and test/conformance/api_test.go, which skips on a start error instead of failing.

The benchmarks in test/benchcmp_sse and test/benchcmp_ws start a std server and do not wait for it at all; they are not this pattern.