diff --git a/fleetd/src/test/java/dev/ltms/fleet/herdr/AgentControlContractTest.java b/fleetd/src/test/java/dev/ltms/fleet/herdr/AgentControlContractTest.java index a480f14..8ec0c82 100644 --- a/fleetd/src/test/java/dev/ltms/fleet/herdr/AgentControlContractTest.java +++ b/fleetd/src/test/java/dev/ltms/fleet/herdr/AgentControlContractTest.java @@ -25,13 +25,23 @@ import static org.junit.jupiter.api.Assumptions.assumeTrue; * So this polls for a real signal instead of guessing a sleep length. * *
What was measured, and what was not. Polling fixes it: 5 standalone runs - * green. The load-bearing half is {@link #waitForText}. With {@link #SHELL_READY_TIMEOUT_MS} - * set to 0 — so input is typed at once, with no settle wait at all — the test still passed 3 of - * 3. So the proven cause is the 800ms READ deadline being too short, not the 1000ms write delay. - * Note the direction, because it matters: typing at 0ms works where typing at 1000ms failed. The - * earlier explanation for this test — that input typed before the prompt is swallowed by the - * shell's startup — is therefore NOT supported by any measurement here. Please do not repeat it - * as the reason; if it were true, 0ms would be worse than 1000ms, and it is better. + * green. The load-bearing half is {@link #waitForText}, and one cell proves it. Keep the old + * 1000ms write sleep and change only the read — the 800ms fixed sleep becomes a 5s poll — and + * the test goes from 0 of 3 passing to 3 of 3. Removing the write wait instead + * ({@link #SHELL_READY_TIMEOUT_MS} set to 0, so input is typed at once) also passes 3 of 3. So + * the cause is the 800ms READ deadline, not the 1000ms write delay. The old version fails every + * time, not sometimes, so "race" is the wrong word for it. The earlier explanation — that input + * typed before the prompt is swallowed by the shell's startup — is not supported by anything + * measured here. Please do not repeat it: if it were true, typing at 0ms would be worse than + * typing at 1000ms, and it is not. + * + *
Where this was measured. A 12-core macOS host, load average 2.6 to 5.9, + * on commit 20c1094. The same four cells were also run under load and gave the same answer, but + * that run is not clean evidence: the load average climbed from 7 to 50 while the cells ran, and + * the old version ran last, at the top of that climb. Above about load 20 everything here is + * slow for reasons that have nothing to do with this seam. So read the claim as "measured near + * idle on a 12-core host", and nothing stronger. If this test fails on a smaller or busier + * machine, raise {@link #OUTPUT_TIMEOUT_MS} before you suspect the seam. * *
{@link #waitUntilSettled} is kept as cheap insurance against that swallow case, not because * anyone showed it was needed. If you want to delete it, the honest test is whether you can make