docs(ci-reds): R1 occurrence on #245, with its merge-base control

Recorded together, because the control is what the occurrence owed.

The occurrence: Test (macos-latest / lua54) on head d9cc0fa, 1984 passed
and 1 failed, panicking at src/async_runtime.rs:2444 with R1's required
fragment. THIS IS R1 despite the new Lua flavor --- the row records
luajit and this is lua54, and flavor is not part of signature matching.
The selector and the fragment are, and both match.

The control: the same job at the branch's EXACT merge base 2e9f62b,
rerun the same hour, green at 1985 passed and 0 failed. Both logs were
preserved before the rerun, so neither result is reconstructed from a
conclusion --- the selector is read as "... ok" in the control's own log.

What that green control establishes is carefully bounded. It does NOT
establish environmental cause and does NOT retire R1; it shows only that
the merge base can pass the same job in the same hour. A RED control
would have established that the branch did not introduce the occurrence,
and that inference is simply unavailable here. R1 remains live either
way under its measurement-design disposition.

Records that R1's assertion omits its measurement --- the same class #244
fixed, and a line my discarded sweep had surfaced --- and that it is
deliberately NOT fixed here. Adding the elapsed value would sharpen the
next failure's evidence and repair nothing about the measurement design
this row is about: that a thread::sleep(15ms) is asserted by comment to
mean the worker picked the job up. That belongs to the async-runtime
lane with the rest of Q#MCI3.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
This commit is contained in:
Levi Neuwirth 2026-08-30 12:02:01 +02:00
parent d9cc0fa58a
commit c21eee6e49
No known key found for this signature in database
2 changed files with 56 additions and 0 deletions

View File

@ -298,6 +298,23 @@ from #171 and #215.
assertion. Note `on:` parses as the **boolean `True`** under YAML 1.1,
so the witness looks up both keys; a naive `d['on']` would raise
before it ever checked anything.
- **PR #245 CI: 13/14, red on `Test (macos-latest / lua54)`.** The
failure is **R1** — `supersede_cancels_in_flight_job_within_50ms`,
fragment `supersede did not cancel within 50ms` — an existing row,
matched by selector and fragment. Its recorded flavor is `luajit` and
this is `lua54`; **flavor is not part of signature matching**.
- **The merge-base control was run rather than the PR job.** The same
job at the branch's exact base `2e9f62b`, rerun the same hour: green,
`1985 passed; 0 failed`, both logs preserved. **A green control does
not establish environmental cause and does not retire R1**; a red one
would have shown the branch did not introduce the occurrence, and
that inference is unavailable. R1 stays live under its
measurement-design disposition.
- **R1's assertion also omits its measurement**, which surfaced in the
#244 sweep I discarded as noise. **It is deliberately NOT fixed
here**: it would sharpen the next failure and repair nothing about
the measurement design R1 is actually about. That is the
async-runtime lane's, with Q#MCI3.
- **D2 AND D3 ARE OWED POST-MERGE**, not skipped. GitHub offers
`workflow_dispatch` only for a workflow already on the default
branch, so neither can run before this lands. Their exact procedures

View File

@ -119,6 +119,45 @@ runs, and only reds that were still readable.
### R1 — supersede cancellation budget
**Occurrence on PR #245, 2026-08-30, with a merge-base control run the
same hour.** Recorded together because the control is what the
occurrence owed.
| field | value |
| --- | --- |
| **occurrence** | `Test (macos-latest / lua54)`, run `33303043179`, job `99234587352`, head `d9cc0fa`. `1984 passed; 1 failed`, panic at `src/async_runtime.rs:2444` with the row's required fragment `supersede did not cancel within 50ms` |
| **merge-base control** | the SAME job at the branch's **exact** merge base `2e9f62b` — run `33277675008`, attempt 2, job `99239538960` — **GREEN**, `1985 passed; 0 failed`, the selector reading `... ok` in its log |
| **both logs preserved** | before the rerun, so neither is reconstructed from a conclusion |
**THIS IS R1, and the new Lua flavor does not change that.** The row
records `macOS / luajit`; this occurrence is `macOS / lua54`. **Flavor
is not part of signature matching** — the selector and the required
fragment are, and both match exactly.
**What the GREEN control establishes, and what it does not:**
* **It does NOT establish environmental cause**, and it does **NOT**
retire R1. A green control shows only that the merge base can pass
the same job in the same hour.
* **A RED control would have established something specific** — that
the branch did not introduce the occurrence. This control was green,
so that inference is unavailable and is not claimed.
* **R1 remains LIVE either way**, under its existing
**measurement-design** disposition. Its retirement condition is
unchanged: the async-runtime lane replaces or justifies the
measurement (Q#MCI3).
**The assertion still omits its measurement.** `started.elapsed()` is
in hand at the panic and the message reports none of it, so this
occurrence's margin is as unrecoverable as every prior one's.
**Recording that is not the same as proposing to fix it here.** Adding
the elapsed value would improve the NEXT failure's evidence and would
repair nothing about the measurement design this row is actually about
— the premise that a `thread::sleep(15ms)` means the worker picked the
job up. That belongs to the async-runtime lane, with the rest of
Q#MCI3.
| field | value |
|---|---|
| **selector** | `--lib async_runtime::tests::supersede_cancels_in_flight_job_within_50ms` |