One skip stands in for 28 named arms across six suites, so a skipped arm and a deleted one are indistinguishable

[OffgridwithJD]

Four check_skip calls stand in for 17 named arms under a name none of those arms has. When the condition fails, the 17 names produce no record at all, and one line appears bearing a name that exists nowhere else:

# test/selftest/340-the-binary-must-be-built-from.sh:676
if [ -z "$_fp_user" ]; then
	check_skip "the unreadable-source refusal" "SKIP  no non-root user to read as; ..."
else
	check "premise: the unprivileged reader can source the staged harness" ...
	check "premise: the tree fingerprints to something when it is readable" ...
	check "premise: the unprivileged read agrees while everything is readable" ...
fi

A reader of that log cannot tell which three arms did not run, and the ledger cannot tell a skipped arm from a deleted one — its rows for those three names have no matching record, exactly as a removed check's would.

Measured, not estimated

Swept every check_skip in test/*.sh and test/selftest/*.sh:

	count
check_skip call sites	25
named by a literal string	21
named by a variable	4
literal skips standing in for named arms in the sibling branch	4
literal skips guarding a block with no named arms	17

The 17 that guard no named arms are fine: the skip is the record, nothing else claimed to run, and nothing is lost. This issue is only about the four.

The four, with the arms each one replaces — every count read off the file by eye, not only from the sweep:

site	arms it stands in for
test/native_parquet_flba.sh:211	6
test/native_parquet_pushdown.sh:214	3
test/sorted_pathkeys.sh:278	5
test/selftest/340-the-binary-must-be-built-from.sh:677	3

17 arms, 4 lines.

The fix already exists in the tree, 32 lines below one of the offenders

340-the-binary-must-be-built-from.sh:709 does it the other way — it skips under each arm's own name:

	for _fp_n in ...; do
		check_skip "$_fp_n" \
			"SKIP  $_fp_n (the unprivileged reader could not fingerprint a readable tree)" \
			"the unprivileged reader could not fingerprint a readable tree"
	done

Three of the four variable-named sites do the same thing (lib.sh:1696 uses "$2", native_groupagg_batch.sh:179 uses "$label"). So this is not a new convention to invent — it is the one already in use, missing at four sites.

Why this is worth fixing beyond tidiness

It is the precondition for arming the orphan guard in #983 / #993. That guard compares the ledger's keys against a run's and finds rows with no matching record. It reports rather than refuses only because of this: on a box with no non-root user, the two 340 rows are live checks with no record, so a gate refusing on absence would redden a correct run. Once a skipped arm records under its own name, absence means removal and the guard can be armed.

Two arms in #993 pin the current shape, so the day it changes they say so rather than the guard quietly becoming armable with nobody noticing.

What I am not claiming

• This hides no failure. A skipped arm is not a passing arm: check_skip records a SKIP verdict and the suite's accounting includes it. The cost is that a reader and the ledger cannot tell which arms were skipped, and that the orphan guard cannot be armed.
• I measured the repository, not every environment. Whether each of the four conditions actually fails anywhere in CI is a separate question; 340's does, on any box without a non-root user, which is why it surfaced.
• The 17/4 split rests on an awk that reads the sibling branch between else and fi. I verified all four by eye afterwards, because my first two sweeps of this produced confident wrong numbers from a broken field split (grep -n emits file:lineno:content, and stripping one colon left the line number on the name).

Found while measuring the false-positive budget for #983's guard. Related: #965, which made the same conversion for the eleven timeout paths.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Uf6UoeBRZYLQZa4KxNiw8a

[OffgridwithJD]

The fix at the four sites is easy. Keeping it fixed is the design question, and I do not think it should be decided by whoever writes the patch. Three mechanisms, with what each costs.

1. A name list in the skip branch (what 340:709 already does)

if [ -z "$_fp_user" ]; then
	for _n in \
		"premise: the unprivileged reader can source the staged harness" \
		"premise: the tree fingerprints to something when it is readable" \
		"premise: the unprivileged read agrees while everything is readable"; do
		check_skip "$_n" "SKIP  $_n (no non-root user to read as)" "no non-root user to read as"
	done
else
	check "premise: the unprivileged reader can source the staged harness" ...

Every name stays a literal at both sites, which is what makes them greppable and readable in a log. The cost is that each name now exists twice, and duplicated cost model must move together is the memory that says what happens next: someone adds a fourth arm to the else and the skip list keeps three.

2. One variable per name, used by both branches

Removes the duplication outright — the list and the arms cannot disagree, by construction.

The cost is that no check call site carries its own name as a literal any more. Every static sweep over check names stops seeing them, including this repository's own guards over check-name shape and my own sweeps in this issue. I think that cost is larger than the duplication it removes, but it is a judgement about which property matters more and I would rather it were yours.

3. A monotone ceiling on the offence, like suites_not_covered

Leave the mechanism at (1) and bound the class:

skips_standing_in_for_named_arms 0     # may only fall

counted by the sweep in this issue, committed in check_ledger_budget.txt, refused if it rises. This catches a new offender, which is the failure mode that produced these four — nobody set out to do it, the shape was just available.

It does not catch drift inside a fixed site: adding a fourth arm and forgetting the skip list leaves the count at zero. That drift is caught by #983's orphan guard instead, in the environment where it matters — the arm has no record there, and the scan names it.

My reading

(1) plus (3). (1) keeps names literal, (3) stops the class growing, and the orphan guard covers the gap (3) leaves. (2) buys drift-freedom with a property the repository uses everywhere.

This is a gate-contract change, same as the list-versus-count bound on #982, so it wants the same scrutiny rather than a patch appearing with a number in it. I have not built any of the three.

One caution on (3) from my own sweeps in this issue: the count is only as good as its extractor, and mine was wrong twice before it was right — grep -n emits file:lineno:content, I stripped one colon, and every "name" was the raw line, so "25 of 25" was an artifact of comparing a line against a name. Any committed number here needs a known-answer premise beside it, the way the gate's census is asserted against the ledger rather than maintained by hand.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Uf6UoeBRZYLQZa4KxNiw8a

[OffgridwithJD]

Correcting this issue: both of its numbers are wrong, and #998 was sized from them. It is six sites and nineteen arms, not four and seventeen.

19 arms, not 17

My sweep's regex required exactly one space between the helper and the name:

^[[:space:]]*(check|check_num|check_text|ans|ansp|ansq) "

sorted_pathkeys.sh writes ansp " with two. Proof, on a two-line fixture holding one ansp " line and one check " line:

my original pattern (one space)      matches: 1
[[:space:]]+ instead                 matches: 2

So sorted_pathkeys:278 stands in for 7 arms, not the 5 I reported. @jdatcmd's #998 lists all seven and says why: two go through ansp, which records under its first argument and is an arm like any other. Corrected per-site counts: flba 6, pushdown 3, sorted_pathkeys 7, 340 3 — 19.

Six sites, not four

My classifier asked, for each literal skip, whether the branch after it held named arms. That misses a skip whose arms are in the branch before it — an outer else:

native_parquet_flba.sh:245      check_skip "the foreign-producer FLBA cases"     <- 6 arms at 225-241, in the THEN branch
native_parquet_pushdown.sh:234  check_skip "the integer-DECIMAL pushdown case"   <- 3 arms at 227-231, same

Both are the outer if python3 -c 'import pyarrow.parquet' guard. So when pyarrow is absent entirely — a plainer environment than "this pyarrow stores decimals unexpectedly", which is the inner case #998 fixes — those nine arms still produce no record under a name none of them has.

My table said those two "guard a block with no named arms", which was the whole basis for exempting them. It was an artefact of a forward-only look.

And the same class is in 340 itself, which I also missed

Forcing _fp_user="" on #998's branch, five more arms produce no record:

an unreadable b.c yields no fingerprint, not a wrong one
an unreadable c.c yields no fingerprint, not a wrong one
control: a readable run still reads fresh
control: and the tree fingerprints again once it is readable
so the verdict is unknown -- UNVERIFIED -- and never stale

They sit behind if [ -z "$_fp_user" ]; then : # already skipped above, and "above" skipped the three premises, not these. Detail and a driven one-line repair are on #998.

What this does not change

The fix pattern and the guard are still the right shape. The under-count means there is more of it than I said, not that any of it was wrong. And the arming precondition for #983's orphan guard is unchanged: it needs every skipped arm to record under its own name, and that is now six sites' worth of work rather than four.

How the error survived: the sweep printed a count with no independently known value beside it. Three sweeps of mine went wrong the same way in one session — grep -n emits file:lineno:content and I stripped one colon, which produced "25 of 25", then "301 registered suites", then "0". What caught those was a premise comparing against a number I had not computed (equals the 252 the gate reported). This one had no such premise, so it survived into an issue and then into someone's PR scope.

[OffgridwithJD]

Third correction, and the last one I will make by sweeping: 28 arms, not 19 and not 17.

#998's outer flba loop lists ten names, four more than the inner six:

pyarrow uuid reads as uuid
pyarrow decimal128 values are exact
crafted out-of-range scale is rejected, not decoded
backend survived the crafted scale

Those four sit between the two gates in the then branch, so the outer gate covers them and the inner one does not. My forward-only classifier never saw the outer gate at all, so it never saw them either.

Reading #998's four loop lists directly:

site	names in the loop
native_parquet_flba.sh outer	10
native_parquet_pushdown.sh outer	3
sorted_pathkeys.sh	7
340 block 1	3
340 arms block	5

The inner flba (6) and pushdown (3) loops name subsets of their outer ones, so the distinct total is 10 + 3 + 7 + 3 + 5 = 28 arms.

Why this figure is read rather than swept, which matters

I wrote a script to count it and it returned 32 for flba and 76 for pushdown. It matched any for ... in loop with a check_skip within six lines, so it swallowed SQL strings, Python fragments and predicate lists from unrelated loops. The numbers looked like measurements and were noise.

So this 28 is read off #998's own loop lists by eye. That is weaker evidence than a sweep when the sweep is right, and stronger than a sweep that is wrong — and on this exact question mine has now been wrong three times for three different reasons:

17  a regex requiring exactly one space, where the file writes `ansp  "`
19  a classifier looking only FORWARD from the skip to an `else`
32/76  a loop matcher with no idea which `for` it was looking at

Each produced a plausible number. The first two reached an issue and then someone's PR scope. The common cause is the one already written down in this repository: a count with no independently known value beside it is unfalsifiable, however carefully the code is written. Every sweep I publish from here states, before its total, a comparison against something I did not compute from the same extraction.

What does not change

The class, the fix pattern, and the arming precondition for #983's orphan guard are all unchanged. #998 now covers all 28 and adds a derived guard over the loops, so this issue is addressed by that PR rather than by a bigger version of itself.