18 lines
2.4 KiB
Markdown
18 lines
2.4 KiB
Markdown
FAIL
|
|
|
|
Ran `cargo test -p ely-platform` (11 + unit tests pass) and `cargo clippy -p ely-platform --all-targets` (clean). The probe ran in a scratch crate that depends on `ely-platform` and talks to a local server.
|
|
|
|
Round 1 defects:
|
|
1. Userinfo bypass: fixed. `secure_host` parses with `Uri`, refuses `@` in the authority, and decides by parsed scheme and host. Covered by unit and integration tests.
|
|
2. Redirects not checked: fixed. Both agents use `max_redirects(0)`, and `fetch` runs every hop through `secure_host`. Covered by `a_redirect_is_followed_on_this_machine_and_refused_when_it_leaves_for_plain_http`.
|
|
3. Stall blocks cancel forever: the caller-facing part is fixed (cancel and the idle error both return). The fix leaves the blocked read behind, see new defect 1.
|
|
4. Inherited `APPIMAGE`: fixed. The policy now depends only on the executable path.
|
|
5. Download error lost on cleanup failure: fixed, with a test that makes the cleanup fail.
|
|
6. Missing logs: fixed. `check` logs host and outcome, and `download` logs cancel and failure. Covered by a test.
|
|
|
|
New defects:
|
|
|
|
1. crates/ely-platform/src/update.rs:182-200, 208-228: A stalled or cancelled download leaks its reader thread and its socket. The socket still has no read timeout. `stream` stops waiting on the channel, but the spawned thread stays blocked in `reader.read` until the peer closes or sends data. A half-open connection (Wi-Fi dropped, CDN hung, no TCP keepalive) never does either, so the thread, the 64 KiB buffer and the connection stay alive for as long as the process runs.
|
|
Scenario (probe): a local server sends the headers and 1000 of 1000000 bytes, then keeps the connection open and silent. Ten `download` calls with `idle` = 200 ms each returned "the download stalled" as expected. 3 s later the process had 13 threads instead of 3, and 20 more TCP descriptors than before (10 client, 10 server). Each "retry" after a stall adds one more. The current test can't see this because its server closes after 60 s and the test process exits first.
|
|
Fix: put the idle timeout on the socket itself, for example a ureq `Transport`/connector that sets `set_read_timeout(idle)` on the `TcpStream`. Then `read` returns, the thread (or the plain loop that can replace it) ends, and the connection drops. Add a test that keeps the connection open, then asserts that the thread or connection is gone after the stall error, for example that the server sees EOF or reset.
|