From c0a000eb4f9790842782084a685a78e45b50508e Mon Sep 17 00:00:00 2001 From: japabu Date: Mon, 28 Sep 2026 14:13:01 +0200 Subject: [PATCH] Disable blocking_read_window behind its filed defect MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The orchestrator's Fast tier and nightly for PR #536 at 5235eda7 hit the same verdict twice, and the round-13 reviewer found the PR leaves the wake and pipe path alone while the two ends spent about 1580 ms of CPU each — consistent with the actuator's 50 ms holds running out, not a lost wake. The issue's verdict also rests on a 3 s duration inside a QEMU test, which the owner rules is metal-only; PR #562 is removing such verdicts. A flaky test is disabled at once, never re-run. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01W6rME2DoqwjcYFStYHHY4j --- .../blocking-read-window-reds-beside-other-guests.md | 12 +++++++++++- src/redlist.rs | 4 ++++ 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/issues/build/blocking-read-window-reds-beside-other-guests.md b/issues/build/blocking-read-window-reds-beside-other-guests.md index aea2f17d339..e0c0b4ecb15 100644 --- a/issues/build/blocking-read-window-reds-beside-other-guests.md +++ b/issues/build/blocking-read-window-reds-beside-other-guests.md @@ -1,5 +1,5 @@ --- -status: open +status: expected-red kind: finding opened: 2026-09-26 --- @@ -30,6 +30,13 @@ Sightings, all on 2026-09-26: and each arm's one red is this sentence (`only 26 of 500` on `main`, `only 27 of 500` on the branch; the branch's red spent `cpu=1568ms` and `cpu=1532ms` of its window). The rate is the same on both arms, so no branch moved it. +- **The orchestrator's Fast tier and nightly for PR #536, both, at `5235eda7`: + 2 of 2 red**, `blocking_read_stress: only 28 of 500 round trips completed + inside 3s — a wake was not delivered`. +- **The round-13 reviewer's finding on #536**: the PR leaves the wake and the + pipe path alone, and the two ends spent about 1580 ms of CPU each, + consistent with the actuator's 50 ms holds running out rather than with a + lost wake. **What the red runs' own logs say against the sentence.** In the 26-of-500 run the two processes spent `cpu=1639ms` and `cpu=1998ms` of the 3.5 s they ran @@ -43,3 +50,6 @@ wake does. progress over the window, not only the count at its end), and a cause for these runs — a lost wake, or a 3 s budget a starved host cannot meet, and if it is the budget, the bound derived rather than measured. + +This verdict rests on a 3 s duration inside a QEMU test, which the owner rules +is metal-only; PR #562 is removing such verdicts. diff --git a/src/redlist.rs b/src/redlist.rs index 8a148a67b2e..f2275c064b6 100644 --- a/src/redlist.rs +++ b/src/redlist.rs @@ -25,6 +25,10 @@ pub struct Disabled { /// Every disabled test. pub const DISABLED: &[Disabled] = &[ + Disabled { + test: "blocking_read_window", + issue: "issues/build/blocking-read-window-reds-beside-other-guests.md", + }, Disabled { test: "console_line_atomicity", issue: "issues/build/console-line-atomicity-loses-five-of-a-thousand-lines-on-ci.md",