From 95058502f5a5d87773592305330426327f6c7386 Mon Sep 17 00:00:00 2001 From: Joseph Ferano Date: Fri, 18 Sep 2026 07:40:55 +0700 Subject: [PATCH] The timing check only has to sit under the timeout Two seconds was measured on one warm machine and has no margin against the 6.8s cold build listening already records. The status and the absence of the frame-boundary sentence are what discriminate; this bound exists only so a timeout cannot be read as an answer, so it moves to 4.5 and says so. --- test/test_dev.ml | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/test/test_dev.ml b/test/test_dev.ml index 6416766..f9f9117 100644 --- a/test/test_dev.ml +++ b/test/test_dev.ml @@ -2354,11 +2354,16 @@ let () = fail "a printing program was diagnosed as one that is not polling, which \ is the defect and not the symptom"; - (* The wait is five seconds, so anything near it is the timeout being - reached rather than a slow machine. Two is the compromise: a cold - [llc] under dune's own parallelism is comfortably inside it, and a - run that blocked is comfortably outside. *) - if took > 2.0 then + (* The only job this number has is to sit under the daemon's own + five-second wait, so that "it answered" and "it gave up" cannot be + confused. It is not a measurement of how fast a module builds, and it + is deliberately not tightened into one: [listening] above records 6.8s + for a cold build under dune's parallelism, and a suite that goes red + on a loaded machine teaches whoever is running it to skim past red. + The two assertions that actually discriminate are the status and the + absence of the frame-boundary sentence; this one only rules out a + timeout that somehow reported success. *) + if took > 4.5 then fail "evaluating against a printing program took %.1fs" took; (* And the program's own text came back on the reply rather than being drained into nothing. *)