Every test in tests/lib.rs fails. Root cause is tests/test_utils/mod.rs, which spawns:
cargo run -- -l <port> -D -L <ws_port> -c measurementservers.crt -k measurementservers.key -w
That invocation no longer matches the CLI:
- there is no
-s, so the binary never enters server mode and exits with Error: Invalid argument '-l';
-D and -w no longer exist;
-c now means client mode, not certificate path.
The spawned process dies immediately, so every test fails with ConnectionRefused after waiting out its timeout.
Secondary problems in the same harness:
measurementservers.crt / .key are not in the repository and nothing generates them, so even a corrected command line cannot start the TLS listener.
- It nests
cargo run inside a test, which contends on the build lock and swallows the startup failure.
- It does not wait for the port to be accepting, so failures surface later and misleadingly.
- Handshake reads use a 1 KiB buffer per message, assuming one protocol message per TCP segment. The server sends
OK and CHUNKSIZE back to back, so one read consumes both and the stream desynchronises.
Three of the tests are additionally wrong on their own terms:
handle_put sends data chunks after a TIME response. TIME means the server is back in its command loop, so the chunk bytes are parsed as commands and the connection is reset.
handle_get_chunks (WebSocket) sends "OK" with no trailing newline, which the line-oriented parser never dispatches.
handle_put_no_result_ws doubles the chunk size without clamping to MAX_CHUNK_SIZE, unlike its plain-TCP counterpart, triggering the desync described in the out-of-range chunk size issue.
Related: the suite is not run in CI at all, which is why this went unnoticed.
I have a fix on a branch (11 passed, 0 failed, stable across repeated runs, ~7s) and can open a PR.
Every test in
tests/lib.rsfails. Root cause istests/test_utils/mod.rs, which spawns:That invocation no longer matches the CLI:
-s, so the binary never enters server mode and exits withError: Invalid argument '-l';-Dand-wno longer exist;-cnow means client mode, not certificate path.The spawned process dies immediately, so every test fails with
ConnectionRefusedafter waiting out its timeout.Secondary problems in the same harness:
measurementservers.crt/.keyare not in the repository and nothing generates them, so even a corrected command line cannot start the TLS listener.cargo runinside a test, which contends on the build lock and swallows the startup failure.OKandCHUNKSIZEback to back, so one read consumes both and the stream desynchronises.Three of the tests are additionally wrong on their own terms:
handle_putsends data chunks after aTIMEresponse.TIMEmeans the server is back in its command loop, so the chunk bytes are parsed as commands and the connection is reset.handle_get_chunks(WebSocket) sends"OK"with no trailing newline, which the line-oriented parser never dispatches.handle_put_no_result_wsdoubles the chunk size without clamping toMAX_CHUNK_SIZE, unlike its plain-TCP counterpart, triggering the desync described in the out-of-range chunk size issue.Related: the suite is not run in CI at all, which is why this went unnoticed.
I have a fix on a branch (11 passed, 0 failed, stable across repeated runs, ~7s) and can open a PR.