steve
e64075d5d7
CI / Test (store) (pull_request) Successful in 8s
CI / Test (rest) (pull_request) Successful in 12s
CI / Build (windows/amd64) (pull_request) Successful in 15s
CI / Lint (pull_request) Successful in 19s
CI / Build (linux/amd64) (pull_request) Successful in 12s
CI / Build (linux/arm64) (pull_request) Successful in 44s
CI / Test (server-http) (pull_request) Successful in 2m55s
e2e / Playwright vs docker-compose (pull_request) Successful in 2m45s
Keep the test WS client actively reading (a real agent always is) so the server-side conn stays registered under parallel load, and drain to completion via condition polling instead of asserting one-shot completeness. The conn could be dropped/unregistered under CI load, making DrainPending correctly no-op (conn==nil) and the test observe a partial/empty drain. -race confirms no production data race; the exactly-5-jobs assertion (proving the per-host mutex blocks double-dispatch) is unchanged. Verified: 0 failures over 25 loaded runs + 4 -race iterations.