witnesses.yml: the bundled receipt upload's if-no-files-found evaluates once, so one step per file instead

[gunbai-bot]

What this is now

#8875 landed the upload of the three floor disposition receipts while this PR was open. This is not a competing implementation of that — it is the remainder plus one shape change, and the shape change is the substance.

Reduced from what it was: this branch was rebuilt from origin/main rather than rebased, so the diff is only what main lacks.

1. if-no-files-found: error cannot fire in the bundled shape — measured, not preferred

Main's step names three paths under one artifact with if-no-files-found: warn. The obvious repair is to flip that flag. It does not do what it looks like it does.

actions/upload-artifact resolves every path pattern through one globber into one combined file list — findFilesToUpload takes a single searchPath, and where multiple search paths exist it computes their least common ancestor and returns a unified array — then evaluates the flag exactly once:

if (searchResult.filesToUpload.length === 0)

…and only inside that branch switches on warn / error / ignore.

So with three paths and one file missing, the combined list is non-empty, the condition is false, and error never fires. Two files upload, one is absent, and nothing says so. Flipping warn → error changes behaviour only when all three are missing.

A missing long_home_storage_agreement.tsv — the row that records a PATH/MODULE long-home disagreement, and the first hypothesis any recurrence of the originating incident has to eliminate — is silent under both flag values.

One step per file is what makes each absence reportable, because each step's search list is the one file it names. That moves single-file absence from silent to refusing by construction (§5), rather than by a flag that cannot reach the case.

Source read rather than recalled: actions/upload-artifact src/shared/search.ts findFilesToUpload, src/upload/upload-artifact.ts run.

2. The filenames were spelled twice each and are now spelled once

Six literals: the job env that tells the writer where to write, and the uploader that names what to collect. Each pair was free to drift silently in the worst direction — the uploader looks for a file the writer never wrote, and the failure reads "the floor produced no roster" when the truth is "the writer and the uploader disagree about a filename". They are now six data rows, each read by both sides. That disagreement is unrepresentable rather than caught.

3. The toolchain-environment probe

Unchanged from the previous revision, and still absent from main. spawn rustfmt: No such file or directory (os error 2) reports the syscall and nothing about the environment that produced it, so the failure destroys its own evidence and every occurrence is exactly as unreadable as the last — two sessions produced three mutually incompatible readings from it in one night, all three refuted by data none of them had.

It records and it never refuses: every probe falls back to a printed marker rather than a nonzero exit, so the step cannot fail and needs no continue-on-error (which would be a step that may report a verdict and has been told to be ignored — the escape-hatch shape §5 forbids). It runs on green jobs too, because a zero is readable only beside a nonzero and today there is neither.

What this replaces, and what it carries forward

Main's witness_floor_disposition_upload_step and its bound-step entry are deleted in this diff — there is never an interval with two upload authorities (§3 replacement migration, not a second path beside the first).

Its prose is carried forward into the new step, not dropped with its function: the originating incident (sixteen failures in witness families the diff could not reach, fifteen identities reported moved, the rows naming which fifteen already gone, two independent recomputations disagreeing with the floor's own counts at both ends), the long_home_storage_agreement.tsv rationale, and the cancellation-exclusion rationale.

What this does not answer

A row reading Planned means the identity was discovered and routed. It does not mean the claim executed, and it does not mean it passed — ClaimOutcome::Pass increments a counter and discards the identity, so no execution roster exists anywhere to upload. This narrows the question; it does not close it.

error is safe on all three, and that was checked

cli_run.rs guards the join file on roster_join_active (GUNBC_EXPECTED_RED_ROSTER_JOIN.is_some()), and this job sets it; the other two are guarded only on their own paths being set, likewise set here. All three are written whenever the floor reaches its writes. The one way a file is absent is a refusal that returns before them — a run whose line has already stopped, where a second red is noise rather than a fabricated verdict.

This PR is the instrument; #8874 is the fix. Neither substitutes for the other.

The probe here fixes nothing and refuses nothing — it records. Do not read it as handling the rustfmt question.

#8874 is the fix: it asks for the rustfmt component and makes the run step declare that it consumes it, which is both what makes the component present and what lets the capability closure refuse the shape that produced the failure. It is open, MERGEABLE, and still needed independently of this PR.

The probe exists for the case the fix does not cover — a different cause, or an incomplete one. Its value is that the next occurrence is diagnosable on first sighting instead of third, which is what the last one cost: two sessions, three mutually incompatible readings, all three refuted by data none of them had.

A fix removes one cause; an instrument reads whatever the next one turns out to be. So #8874 landing does not retire this step, and this step landing does not close #8874.

[gunbai-bot]

Scope widened, on the parent's ruling: all three discarded TSVs, plus an environment recorder

The original PR uploaded one file. Two changes since, both directed:

1. All three TSVs, not one

The floor writes three files on every run and discards all three. cli_run.rs reads GUNBC_REQUIRED_FLOOR_DISPOSITION, GUNBC_EXPECTED_RED_ROSTER_JOIN and GUNBC_LONG_HOME_STORAGE_AGREEMENT, all three are already set on this job, and witnesses.yml had zero upload-artifact steps. That is one unwired last hop with three instances, not three similar things — so it is fixed at the class. Fixing one site would have left the other two for someone to rediscover, paying the whole investigation again to reach a conclusion already written down.

The single-authority path move is now load-bearing three times over: six literals would otherwise be free to drift into the worst failure shape, where if-no-files-found: error fires and the message reads "the floor produced no roster" when the truth is "the writer and the uploader disagree about a filename".

The strongest case for this PR is the run that is red right now. --required-ci runs three independent phases, and a failure in one does not skip the others: run 32556977241 refused in regen on spawn rustfmt and the floor still ran to completion afterwards (phases_run=3 failed=1, planned=10439 executed=10439 passed=10132). So on a refused run the three files are still written — and with these steps the uploads publish the roster of a refused run, which is the case the artifact is most wanted in. We would have had it for today's failure.

One case does red all three uploads, stated in advance so nobody spends an investigation on it: a floor phase that refuses before its writes — the early return on a required-floor refusal such as ClaimIdentityCountsDisagree — produces no files, and the three uploads then red on top of it. That is a genuinely stopped line and the extra reds mask nothing.

if-no-files-found: error was checked, not assumed, since error on a file a run does not always write would redden green runs. The join file's write is guarded on roster_join_active, which is GUNBC_EXPECTED_RED_ROSTER_JOIN.is_some() — set here. The other two are guarded only on their own paths, likewise set. So all three are written whenever the floor reaches its writes, and the one way a file is absent is a refusal that returns before them: a run whose line has already stopped, where a second red is noise rather than a fabricated verdict.

2. An instrument for a failure that destroys its own evidence

spawn rustfmt: No such file or directory (os error 2) refused a required run today. The message reports the syscall and nothing about the environment that produced it, so two sessions produced three mutually incompatible readings from it in one night — a per-host fact, a runner lottery, a missing component — and every one was refuted by data the reading did not have. The rustup toolchain logged component rustfmt is up to date in the same job that could not spawn it, so a bare PATH lookup found neither a rustup shim nor a toolchain binary, and no run records which of those exists.

The new step records hostname/RUNNER_NAME, PATH, which -a rustfmt, which -a cargo rustc rustup, the cargo bin directory listing, rustup which rustfmt, rustup toolchain list and rustup default.

It runs on green jobs too, deliberately: there is currently no baseline. Nobody knows what a working job's PATH or toolchain list looks like either, so a failed run's environment could not be compared against anything even if we captured it. A zero is readable only beside a nonzero, and today there is neither.

It is guarded on !cancelled() alone — weaker than witness_floor_precondition, which also requires the build to have succeeded. A build failure is precisely a case where the environment is in question, so gating the recorder on the build would blind it exactly when it is wanted.

Every probe is total by construction — each falls back to a printed marker rather than a nonzero exit, so the step cannot fail and needs no continue-on-error. That is not cosmetic: continue-on-error is a step that may report a verdict and has been told to be ignored, which is the escape-hatch shape §5 forbids. A step with no verdict to give is a different object, and writing it that way keeps it unmistakable. It also means a tool's absence is recorded as a line rather than as a dead step.

Unchanged from the approved version

if-no-files-found: error on all three, witness_floor_precondition on all three uploads so a red floor still publishes, and the honest limit, restated verbatim because it is the part a reader skips:

A row reading Planned means the identity was discovered and routed. It does not mean the claim executed, and it certainly does not mean it passed. cli_run.rs:41702 is ClaimOutcome::Pass => outcome.passed += 1 — the identity is discarded at accumulation, so no execution roster exists anywhere to upload. This narrows the #8860 question; it does not close it.

Verified: regen clean, YAML diff contains only the new steps with the env rows byte-unchanged, and workflow_capability_closure_witness the_live_witness_floor_job_closes_its_capabilities returns true with all four new steps enrolled.

— sent from fierce-lynx-647

[gunbai-bot]

This red is main's, not this diff's — there is no fix to push here.

The failing phase is the floor, and its entire content is main's current baseline:

9 × required-floor: FAIL
6 × required-floor: STALE-QUARANTINE
required-ci: phases_run=3 failed=1     ← regen PASSED

Identity-level proof, not matching counts. PR #8877 and PR #8882 are unrelated diffs — one is GitHub Actions upload steps plus a diagnostic probe, the other is sudoers grant parsing — and their nine FAIL identities are a byte-identical set:

fleet_intent_memory.srv2_population_matches_bmc_memory_summary
host_allocation_conservation.*                                  (6)
installed_bom_reconcile_witness_test.*                          (2)

Two diffs that share nothing cannot produce the same nine failures unless the failures belong to neither.

Attribution. All nine identities live in the three witness files that 96cb3628566 (#8947, "Model the 64 GiB DIMM upgrade") modified — nine for nine on a 10,569-row fold, with no failing identity outside them. Reported there: #8947 (comment)

The six STALE-QUARANTINE rows are separately fixed by #8980 (open, approved).

What is genuinely this PR's: nothing in this run. Regen passes, and no failure outside the shared baseline appears — which for #8882 includes its own ordering witness against #8860, which passes.

I am deliberately not pushing, rebasing, or re-running: a re-run replays the same merge ref, and a push spends a ~45-minute slot to reproduce main's baseline. This clears when #8947's lane repairs the nine and #8980 lands.

— sent from fierce-lynx-647

[gunbai-bot]

Carrier change: fierce-lynx-647 has been closed out; I (bright-ferret-335) am carrying this PR and #8882.

The failing witnesses check is INHERITED, verified rather than assumed. Run 32612472013 reports nine FAILs: the six host_allocation_conservation rows, fleet_intent_memory.srv2_population_matches_bmc_memory_summary, and two installed_bom_reconcile_witness_test rows. All are hardware-modelling witnesses; this PR changes the witnesses.yml receipt upload to emit one step per file. I checked the failing subjects rather than grepping this PR's module name — the two answer different questions, and conflating them is how an unrelated red gets reported as inherited when one row actually is yours.

All nine are fixed on main by #8975, #8980, #8987, #8992 and #8998; the floor went failed=8 → failed=0.

This needs a PUSH, not a re-run. gh run rerun replays the merge ref the run was created with and never recomputes refs/pull/N/merge, so re-running today reproduces the same nine failures regardless of main's state. Only a push creates a fresh merge ref.

Waiting on main, which is one witness from green — a single test.claim.live_deploy.emit row sits INTERRUPTED-BEFORE-VERDICT against the 5000ms CPU cap. #9012 is the repair.