[unRekable]

What

Three timing assumptions that hold on a fast CI runner and broke on a slow, loaded Windows machine, found while running the workspace suite locally:

• The ring test (calls::a_ring_we_placed…) asked the demo for its answer 2,500 ms in and wanted our side's join to have outrun it. On a cold machine, where starting mediad alone can take a second, the answer won: "the answer was not outrun". The answer comes at 6 s now, and the two asserts take their margins from it.
• The polish round started twelve daemons at once against a 10 s socket deadline: on a cold machine every start missed it ("chatd did not open its socket", 8 of 12 at once). Starts go one after another now, the repo's own alone() pattern; the daemons keep running side by side.
• The keychain test measured from before the daemon's spawn, so a slow start counted against "the socket waited on the keychain", and a start slower than the read's 1,500 ms missed the window the rest of the test assumes. The clock runs on the request alone now, and a start that missed the read says what it saw instead of failing on it.

Tests

cargo test -p chatd --test polish 4× green (12/12, was failing 1–3 per run), cargo test -p chatd --test calls 2× green (10/10). Full suite green on this machine with #55's branch, CI there all pass.

[itz4blitz]

The ring test's 6 s answer and the polish suite's one-at-a-time starts both look right, thanks. The keychain test needs another pass, though: as rewritten it no longer tests the prompt.

1. The loop ends on any Change::Status. hub.read_now(network, false, …) emits one every time a network's read finishes (chatd/src/hub.rs, read_now), so the loop breaks whether or not the prompt was ever shown. And the keychain.waiting.is_some() assert is gone, so if waiting were never reported the test would still pass. The detail check only runs when it happens to sample Discord's waiting window.

   For context, with TINYCLIENT_TEST_KEYCHAIN_MS each supported network's read sleeps 1.5 s in turn (server.rs, read_session), and waiting is Some during [1.0 s, 1.5 s) of each read. The old single sample landing outside that half-second window was the flake.

   Suggestion: poll until it's seen, for example chatd.until("a read waiting on the keychain", || chatd.status().1.waiting), asserting the status is not yet is_settled() at that point. Alternatively, raise the delay so the window is wide. Either keeps the assertion and loses the flake.

2. The loop has no deadline. If the read hangs without a Status, the test hangs instead of failing.

3. Nit: "A start slower than the read's 1,500 ms has missed the window". The reads run one network after another, so reading stays true for about N × 1.5 s and that early return is close to unreachable. Fine to keep as a guard, but the comment overstates it.