Test 339 fails intermittently with `curl returned 56, when expecting 0` (CURLE_RECV_ERROR) — roughly 1-2 failures per 8 isolated runs, and it has shown up in full 1-1400 runs. Confirmed pre-existing: a pristine binary built from main (a6a168e) flakes at the same rate as the current WebSocket branch, so this is not a regression from #139 work.
The response is chunked with a chunk extension (`21;heresatest=moooo`) and a trailer (`chunky-trailer`) and no Content-Length; the failure is timing-dependent (likely a race in the read path around the final chunk/trailer when the server's FIN lands in a particular position relative to the buffered bytes). A manual mock-server reproduction of the same bytes consistently succeeds, so the trigger seems to involve sws's write pacing.
Repro: `for i in $(seq 8); do ./scripts/run-curl-tests.sh 339 | grep -c '^FAIL'; done`
Test 339 fails intermittently with `curl returned 56, when expecting 0` (CURLE_RECV_ERROR) — roughly 1-2 failures per 8 isolated runs, and it has shown up in full 1-1400 runs. Confirmed pre-existing: a pristine binary built from main (a6a168e) flakes at the same rate as the current WebSocket branch, so this is not a regression from #139 work.
The response is chunked with a chunk extension (`21;heresatest=moooo`) and a trailer (`chunky-trailer`) and no Content-Length; the failure is timing-dependent (likely a race in the read path around the final chunk/trailer when the server's FIN lands in a particular position relative to the buffered bytes). A manual mock-server reproduction of the same bytes consistently succeeds, so the trigger seems to involve sws's write pacing.
Repro: `for i in $(seq 8); do ./scripts/run-curl-tests.sh 339 | grep -c '^FAIL'; done`