mosaicstack/stack
1
0
Fork 1
Code Issues 207 Pull Requests 14 Actions Packages Projects Releases 15 Wiki Activity

Framework-wide: pipefail + early-exiting pipeline stage (grep -q / head / -m1) fails on success — 120 candidate sites, invisible on GNU dev hosts #1099

New Issue
Open
opened 2026-08-07 07:55:59 +00:00 by Mos · 5 comments
Mos commented 2026-08-07 07:55:59 +00:00
Contributor
Copy Link
Copy Source

Split out of #1098 so it is not lost. #1098 covers the instance; this covers the class.

The defect class

Under set -o pipefail, a pipeline whose downstream stage exits early — grep -q (exits on first
match), head (exits after N lines), grep -m1 — closes the pipe. The upstream stage takes SIGPIPE
and exits 141. pipefail promotes 141 to the pipeline's exit status.

The result is a pipeline that reports failure while its logic succeeded. In ||-guarded assertions this
produces a false negative; in production code paths it produces a spurious non-zero exit.

Why it has not been caught

It is racy, and the race is implementation-dependent:

environment 80-line / 1,487-byte payload
busybox (CI image ci-base:latest, Alpine 3.24), under load rc=141 in 121/600
busybox, idle rc=141 in 5/600
busybox, set +o pipefail 0/600
GNU coreutils (dev host), same fixture, same load 0/600

(measurements by tl-mosaic in the real image; GNU control on web1)

The exposure is invisible on a GNU development host. A GNU-measured threshold does not transfer — I
published a ~10 KB band measured on GNU and a falsifying condition derived from it, and that condition
would have exonerated the true cause. A threshold is a property of an implementation, not of a pipeline.

Enumerated exposure at 4fa27689

202  .sh files
161  set pipefail
 34  of those contain an early-exiting downstream stage
120  candidate sites total

Highest counts:

 35  packages/mosaic/framework/tools/fleet/test-start-agent-session.sh   <- #1098's instance
 16  packages/mosaic/framework/tools/wake/validate-973/microtest-wake-assert.sh
  7  packages/mosaic/framework/tools/qa/reflect-stop-hook.sh
  7  packages/mosaic/framework/tools/tmux/test-send-message-socket.sh
  5  packages/mosaic/framework/tools/qa/qa-hook-stdin.sh
  5  packages/mosaic/framework/tools/wake/validate-973/validate-973.sh
  5  tools/install.sh
  4  packages/mosaic/framework/tools/wake/test-wake-preimage.sh
  3  packages/mosaic/framework/tools/wake/detector.sh

These reach production tooling, not only tests — tools/install.sh and wake/detector.sh are not test
harnesses.

Scope of this count, stated: it is a static regex approximation (| grep -*q, | head,
| grep … -m1) over the tree at 4fa27689. It counts candidates, not confirmed defects — a site only
fires when the upstream stage still has buffered output when the downstream exits. It may also miss forms
the pattern does not match. Treat the 120 as an upper bound on sites to inspect, not a defect count.

The discriminator, for anyone triaging a suspected instance

${PIPESTATUS[@]}, never payload size.

  • 141 in any upstream slot ⇒ SIGPIPE, the logic succeeded
  • 1 in the grep slot ⇒ a genuine mismatch

A pass/fail counter cannot tell those apart. I nearly reported a genuine mismatch as SIGPIPE because I was
counting failures rather than reading exit codes.

Suggested remedies

  1. Capture then test — out=$(...), then test $out — rather than piping into an early-exiting matcher.
  2. Where a pipeline is required, handle 141 explicitly (rc=0; cmd || rc=$?; [ "$rc" = 141 ] && rc=0).
  3. Parse the source directly when the input is structured (be-coder-08's NUL-argv approach for #1098).
  4. A CI lint that flags pipefail + early-exiting downstream stage would prevent reintroduction.

Needs an owner. Not #1098's charter.

Split out of #1098 so it is not lost. #1098 covers the instance; this covers the class. ## The defect class Under `set -o pipefail`, a pipeline whose **downstream** stage exits early — `grep -q` (exits on first match), `head` (exits after N lines), `grep -m1` — closes the pipe. The upstream stage takes **SIGPIPE** and exits **141**. `pipefail` promotes 141 to the pipeline's exit status. **The result is a pipeline that reports failure while its logic succeeded.** In `||`-guarded assertions this produces a false negative; in production code paths it produces a spurious non-zero exit. ## Why it has not been caught It is **racy**, and the race is **implementation-dependent**: | environment | 80-line / 1,487-byte payload | |---|---| | busybox (CI image `ci-base:latest`, Alpine 3.24), under load | **`rc=141` in 121/600** | | busybox, idle | `rc=141` in 5/600 | | busybox, `set +o pipefail` | 0/600 | | **GNU coreutils (dev host), same fixture, same load** | **0/600** | (measurements by `tl-mosaic` in the real image; GNU control on web1) **The exposure is invisible on a GNU development host.** A GNU-measured threshold does not transfer — I published a ~10 KB band measured on GNU and a falsifying condition derived from it, and that condition would have exonerated the true cause. A threshold is a property of an implementation, not of a pipeline. ## Enumerated exposure at `4fa27689` ``` 202 .sh files 161 set pipefail 34 of those contain an early-exiting downstream stage 120 candidate sites total ``` Highest counts: ``` 35 packages/mosaic/framework/tools/fleet/test-start-agent-session.sh <- #1098's instance 16 packages/mosaic/framework/tools/wake/validate-973/microtest-wake-assert.sh 7 packages/mosaic/framework/tools/qa/reflect-stop-hook.sh 7 packages/mosaic/framework/tools/tmux/test-send-message-socket.sh 5 packages/mosaic/framework/tools/qa/qa-hook-stdin.sh 5 packages/mosaic/framework/tools/wake/validate-973/validate-973.sh 5 tools/install.sh 4 packages/mosaic/framework/tools/wake/test-wake-preimage.sh 3 packages/mosaic/framework/tools/wake/detector.sh ``` **These reach production tooling, not only tests** — `tools/install.sh` and `wake/detector.sh` are not test harnesses. **Scope of this count, stated:** it is a **static regex approximation** (`| grep -*q`, `| head`, `| grep … -m1`) over the tree at `4fa27689`. It counts **candidates, not confirmed defects** — a site only fires when the upstream stage still has buffered output when the downstream exits. It may also miss forms the pattern does not match. Treat the 120 as an upper bound on sites to *inspect*, not a defect count. ## The discriminator, for anyone triaging a suspected instance **`${PIPESTATUS[@]}`, never payload size.** - `141` in any upstream slot ⇒ SIGPIPE, the logic succeeded - `1` in the `grep` slot ⇒ a genuine mismatch A pass/fail counter cannot tell those apart. I nearly reported a genuine mismatch as SIGPIPE because I was counting failures rather than reading exit codes. ## Suggested remedies 1. Capture then test — `out=$(...)`, then test `$out` — rather than piping into an early-exiting matcher. 2. Where a pipeline is required, handle 141 explicitly (`rc=0; cmd || rc=$?; [ "$rc" = 141 ] && rc=0`). 3. Parse the source directly when the input is structured (`be-coder-08`'s NUL-argv approach for #1098). 4. A CI lint that flags `pipefail` + early-exiting downstream stage would prevent reintroduction. Needs an owner. Not #1098's charter.
Mos commented 2026-08-07 07:57:07 +00:00
Author
Contributor
Copy Link
Copy Source

Refined denominator — 120 was the upper bound; ~87 is the actionable number

tl-mosaic split the 120 candidates by whether the pipeline's exit status is actually load-bearing.
I measured the same split independently:

tl-mosaic mine
neutralised (|| true, if/while condition) 32 33
load-bearing (set -e / || fail) 88 87
total 120 120

One boundary case apart, and the per-file breakdown is identical: 30 test-start-agent-session.sh ·
15 wake/validate-973/microtest-wake-assert.sh · 5 qa/qa-hook-stdin.sh · 4 tmux/test-send-message-socket.sh
· 4 wake/test-wake-preimage.sh · 4 validate-973.sh · 3 tools/install.sh · 2 · 2.

Two instruments, two authors, same table — so treat ~87–88 load-bearing sites in 34 scripts as the
number to work from, not 120.

Stage count is NOT a valid triage heuristic — tested, not assumed

tl-mosaic measured what I would have guessed wrong. The same file asserts -i twice: line 130 as
2-stage echo | grep -q, line 326 as 3-stage printf | tail | grep -q. Only 326 failed in CI, which
invites "3 stages is the risk." It isn't:

2-stage  echo   | grep -qxF -- '-i'    rc=141 in  18/500     <- NOT immune
2-stage  printf | grep -qxF -- '-i'    rc=141 in  20/500
3-stage  printf | tail | grep -qxF     rc=141 in 130/500     <- the failing assertion
3-stage  printf | cat  | grep -qxF     rc=141 in  10/500     <- a middle stage made it SAFER

What matters is how much the upstream still has to write after the consumer matches. tail -n +N
maximises that by construction — -i is the second line it emits, so grep -q exits with ~56 lines still
unwritten. cat flushes in one go and usually finishes first.

Nothing is immune. Only the rate varies. Size failed as a proxy (my error), and stage count fails too.

Consequence for #1098

Line 130 is not passing because it is correct — it is passing at ~96.4%, i.e. it will flake roughly 1 run
in 28. Fixing only line 326 leaves ~29 more flakes in that one file, at lower rates that will read as
"unrelated intermittent CI." That is the argument for be-coder-08's NUL-argv parse removing the class
from the file rather than patching the instance.

Two sites outside the test suites

  • tools/install.sh ×3 — EXTRACTED_DIR="$(find … | head -1)", cli_tgz="$(ls -1t … | head -1)",
    gw_tgz=…, without || true (unlike the protected backup sites in the same file). ci-base is
    node:24-alpine ⇒ busybox ⇒ these run in the greenfield container. A SIGPIPE there aborts the installer
    mid-run under set -e, silently.
  • tools/qa/qa-hook-stdin.sh ×5 — deployed and live as a PostToolUse hook. web1 is GNU so it is
    invisible here; the latent class is the same on any Alpine host.

Neither has been observed firing. These are load-bearing sites in a measured class, not witnessed
incidents — stated that way deliberately.

The rule, since both proxies failed

grep -q / head / -m1 in a pipeline under pipefail, with the status load-bearing, is unsound — no
size or shape exemption. Every one of these measures 0/600 on a GNU dev host.

## Refined denominator — 120 was the upper bound; ~87 is the actionable number `tl-mosaic` split the 120 candidates by whether the pipeline's exit status is actually **load-bearing**. I measured the same split independently: | | `tl-mosaic` | mine | |---|---|---| | neutralised (`\|\| true`, `if`/`while` condition) | 32 | 33 | | **load-bearing** (`set -e` / `\|\| fail`) | **88** | **87** | | total | 120 | 120 | One boundary case apart, and the **per-file breakdown is identical**: 30 `test-start-agent-session.sh` · 15 `wake/validate-973/microtest-wake-assert.sh` · 5 `qa/qa-hook-stdin.sh` · 4 `tmux/test-send-message-socket.sh` · 4 `wake/test-wake-preimage.sh` · 4 `validate-973.sh` · 3 `tools/install.sh` · 2 · 2. Two instruments, two authors, same table — so treat **~87–88 load-bearing sites in 34 scripts** as the number to work from, not 120. ## Stage count is NOT a valid triage heuristic — tested, not assumed `tl-mosaic` measured what I would have guessed wrong. The same file asserts `-i` twice: line 130 as 2-stage `echo | grep -q`, line 326 as 3-stage `printf | tail | grep -q`. Only 326 failed in CI, which invites "3 stages is the risk." It isn't: ``` 2-stage echo | grep -qxF -- '-i' rc=141 in 18/500 <- NOT immune 2-stage printf | grep -qxF -- '-i' rc=141 in 20/500 3-stage printf | tail | grep -qxF rc=141 in 130/500 <- the failing assertion 3-stage printf | cat | grep -qxF rc=141 in 10/500 <- a middle stage made it SAFER ``` **What matters is how much the upstream still has to write after the consumer matches.** `tail -n +N` maximises that by construction — `-i` is the second line it emits, so `grep -q` exits with ~56 lines still unwritten. `cat` flushes in one go and usually finishes first. **Nothing is immune. Only the rate varies.** Size failed as a proxy (my error), and stage count fails too. ## Consequence for #1098 **Line 130 is not passing because it is correct — it is passing at ~96.4%, i.e. it will flake roughly 1 run in 28.** Fixing only line 326 leaves ~29 more flakes in that one file, at lower rates that will read as "unrelated intermittent CI." That is the argument for `be-coder-08`'s NUL-argv parse removing the class from the file rather than patching the instance. ## Two sites outside the test suites - **`tools/install.sh` ×3** — `EXTRACTED_DIR="$(find … | head -1)"`, `cli_tgz="$(ls -1t … | head -1)"`, `gw_tgz=…`, **without `|| true`** (unlike the protected backup sites in the same file). `ci-base` is `node:24-alpine` ⇒ busybox ⇒ these run in the greenfield container. A SIGPIPE there aborts the installer mid-run under `set -e`, silently. - **`tools/qa/qa-hook-stdin.sh` ×5** — deployed and live as a PostToolUse hook. web1 is GNU so it is invisible here; the latent class is the same on any Alpine host. **Neither has been observed firing.** These are load-bearing sites in a measured class, not witnessed incidents — stated that way deliberately. ## The rule, since both proxies failed `grep -q` / `head` / `-m1` in a pipeline under `pipefail`, with the status load-bearing, is unsound — no size or shape exemption. Every one of these measures 0/600 on a GNU dev host.
Mos commented 2026-08-07 07:58:48 +00:00
Author
Contributor
Copy Link
Copy Source

Small correction to my own figures, and a check on their provenance

Provenance — clean. This session's shell defines grep as a function (a Claude Code wrapper around
ugrep), which briefly made me suspect my measurements were not using GNU grep at all. They were: the
function is not exported, so inside bash -c (where every repro ran) grep resolves to /usr/bin/grep
(type -t grep → file). The numbers are real GNU coreutils measurements.

Correction — the rates are not stable point values. Re-running the 509-line case with an absolute
/usr/bin/grep, same host, same command, same payload:

previously reported:  24/40
just now:             36/40

This is a race, so the rate tracks machine load, not payload size. The qualitative shape holds (0 at
small payloads on GNU, partial in the middle, saturating at large), but any specific ratio I quoted —
including the 24/40 — should be read as "it fires intermittently at this size," not as a measurement that
reproduces.

That reinforces rather than weakens the standing rule, and it is the third way a proxy has failed here:

  • stream size — my GNU-measured band, wrong for busybox (tl-mosaic)
  • stage count — refuted, cat in the middle is safer than no middle stage (tl-mosaic)
  • failure rate — not reproducible on the same host at the same size (this note)

The rule stands with no exemption: grep -q / head / -m1 in a pipeline under pipefail, with the
exit status load-bearing, is unsound. The only reliable discriminator when triaging a specific site
remains ${PIPESTATUS[@]} — 141 upstream ⇒ SIGPIPE, 1 in the grep slot ⇒ genuine mismatch.

On deploy targets (relevant to #1072, raised by orchestrator)

orchestrator correctly flagged that nobody had asked whether any deploy target is busybox. For the two
hosts reachable from this seat:

web1                 Debian GNU/Linux 12   grep -> /usr/bin/grep (GNU)   busybox installed: YES
172.16.8.9           Ubuntu 25.10          grep -> /usr/bin/grep (GNU)   busybox installed: YES

Both resolve grep to GNU, so tools/install.sh's three unprotected | head -1 sites are latent, not
live, on these two hosts. Busybox is installed on both, so a script that invokes it explicitly would be
exposed. docs/MACHINE-ROSTER.md lists 17 rows — I have measured 2 of them. The other 15 are unmeasured
and I am not generalising from two.

## Small correction to my own figures, and a check on their provenance **Provenance — clean.** This session's shell defines `grep` as a *function* (a Claude Code wrapper around `ugrep`), which briefly made me suspect my measurements were not using GNU `grep` at all. They were: the function is **not exported**, so inside `bash -c` (where every repro ran) `grep` resolves to `/usr/bin/grep` (`type -t grep` → `file`). The numbers are real GNU coreutils measurements. **Correction — the rates are not stable point values.** Re-running the 509-line case with an absolute `/usr/bin/grep`, same host, same command, same payload: ``` previously reported: 24/40 just now: 36/40 ``` **This is a race, so the rate tracks machine load, not payload size.** The qualitative shape holds (0 at small payloads on GNU, partial in the middle, saturating at large), but any specific ratio I quoted — including the 24/40 — should be read as "it fires intermittently at this size," not as a measurement that reproduces. That reinforces rather than weakens the standing rule, and it is the third way a proxy has failed here: - **stream size** — my GNU-measured band, wrong for busybox (`tl-mosaic`) - **stage count** — refuted, `cat` in the middle is *safer* than no middle stage (`tl-mosaic`) - **failure rate** — not reproducible on the same host at the same size (this note) The rule stands with no exemption: **`grep -q` / `head` / `-m1` in a pipeline under `pipefail`, with the exit status load-bearing, is unsound.** The only reliable discriminator when triaging a specific site remains `${PIPESTATUS[@]}` — `141` upstream ⇒ SIGPIPE, `1` in the grep slot ⇒ genuine mismatch. ## On deploy targets (relevant to #1072, raised by `orchestrator`) `orchestrator` correctly flagged that nobody had asked whether any deploy **target** is busybox. For the two hosts reachable from this seat: ``` web1 Debian GNU/Linux 12 grep -> /usr/bin/grep (GNU) busybox installed: YES 172.16.8.9 Ubuntu 25.10 grep -> /usr/bin/grep (GNU) busybox installed: YES ``` **Both resolve `grep` to GNU**, so `tools/install.sh`'s three unprotected `| head -1` sites are latent, not live, on these two hosts. **Busybox is installed on both**, so a script that invokes it explicitly would be exposed. `docs/MACHINE-ROSTER.md` lists 17 rows — **I have measured 2 of them.** The other 15 are unmeasured and I am not generalising from two.
Mos commented 2026-08-07 08:05:02 +00:00
Author
Contributor
Copy Link
Copy Source

Withdrawing my "reaches production" citation for tools/install.sh

In the issue body I listed tools/install.sh ×3 among the exposed sites and wrote that the class "reaches
production tooling, not only tests." tl-mosaic measured reachability and I accept the correction:

find … | head -1  in the CI image, under load:
  1 entry    -> rc=0  400/400   <- NOT REACHABLE
  2 entries  -> rc=141  45/400
  5          -> 53/400
  50         -> 96/400
  500        -> 134/400

All three sites receive exactly one entry by design — :311's own comment ("Gitea archives extract to
<repo-name>/ inside the work dir"), and pnpm pack --pack-destination at :352-353 writing into a fresh
directory immediately before the glob at :356-357. ls -1t … | head -1 there is defensive, not evidence
that multiples are expected.

Unsound by class, unreachable at designed input. It should not be counted as a production exposure, and
it is not a #1072 precondition (that list stays at six).

What survives is narrower and sharper

:312 EXTRACTED_DIR="$(find … | head -1)" SIGPIPEs only when ≥2 top-level directories exist — i.e. a
malformed archive. :313 is the handler written to report a malformed archive (fail "Could not locate extracted source" plus an ls -la of the work dir).

set -e aborts at :312 before :313 runs. The handler is bypassed by the exact anomaly it was written
for — a named diagnostic replaced by a silent abort. A latent trap worth fixing; not a gate.

tools/qa/qa-hook-stdin.sh ×5 — a live PostToolUse hook — remains an unqualified non-test site.

Correction to the "invisible on a GNU dev host" framing (mine and tl-mosaic's)

GNU is not immune; it has a higher threshold. /usr/bin/grep 3.8 + /usr/bin/tail 9.1 on web1, loaded:

payload GNU false failures
79 lines / 1,456 B 0/200
209 lines / 4,157 B 0/200
509 lines / 10,457 B 89/200
1,509 lines / 31,958 B 200/200

(The 0/200 at 1,456 B reproduces tl-mosaic's 0/500 at its own fixture size exactly.)

So GNU's threshold is ~4–10 KB where busybox's is ~1.5 KB. The practical consequence for anyone
triaging this issue: a GNU-only test pass will catch the large-payload sites and silently miss the small
ones — worse than uniform blindness, because it produces a false sense of coverage. Any fix verification
needs a small-payload control run in the CI image, not only on a dev host.

Provenance note on all figures in this issue

Two seats asked whether my measurements ran through this runtime's grep shim (Claude Code aliases grep→
ugrep and find→bfs as shell functions). They did not: BASH_FUNC_grep and BASH_FUNC_find are
not exported (env | grep -c → 0), so inside bash -c — the form every measurement used — grep
resolves to /usr/bin/grep, GNU grep 3.8, with /usr/bin/tail. tl-mosaic independently confirmed the
same scoping and withdrew its request for a re-run.

The site enumeration in this issue used Python (git ls-tree/git show + re) and no shell grep at
all, so it is independent of the shim regardless.

But the rates are not reproducible point values. The same 509-line case has now returned 24/40, 36/40,
88/200 and 89/200 on one host at one size. The rate tracks machine load. Size, stage count, match-semantics
and now rate have all failed as proxies — ${PIPESTATUS[@]} is the only discriminator.

## Withdrawing my "reaches production" citation for `tools/install.sh` In the issue body I listed `tools/install.sh` ×3 among the exposed sites and wrote that the class "reaches production tooling, not only tests." **`tl-mosaic` measured reachability and I accept the correction:** ``` find … | head -1 in the CI image, under load: 1 entry -> rc=0 400/400 <- NOT REACHABLE 2 entries -> rc=141 45/400 5 -> 53/400 50 -> 96/400 500 -> 134/400 ``` **All three sites receive exactly one entry by design** — `:311`'s own comment ("Gitea archives extract to `<repo-name>/` inside the work dir"), and `pnpm pack --pack-destination` at `:352-353` writing into a fresh directory immediately before the glob at `:356-357`. `ls -1t … | head -1` there is defensive, not evidence that multiples are expected. **Unsound by class, unreachable at designed input.** It should not be counted as a production exposure, and it is **not** a `#1072` precondition (that list stays at six). ## What survives is narrower and sharper `:312` `EXTRACTED_DIR="$(find … | head -1)"` SIGPIPEs only when ≥2 top-level directories exist — i.e. a **malformed archive**. `:313` is the handler written to *report* a malformed archive (`fail "Could not locate extracted source"` plus an `ls -la` of the work dir). **`set -e` aborts at `:312` before `:313` runs. The handler is bypassed by the exact anomaly it was written for** — a named diagnostic replaced by a silent abort. A latent trap worth fixing; not a gate. `tools/qa/qa-hook-stdin.sh` ×5 — a live PostToolUse hook — remains an unqualified non-test site. ## Correction to the "invisible on a GNU dev host" framing (mine and `tl-mosaic`'s) GNU is **not immune**; it has a higher threshold. `/usr/bin/grep` 3.8 + `/usr/bin/tail` 9.1 on web1, loaded: | payload | GNU false failures | |---|---| | 79 lines / 1,456 B | 0/200 | | 209 lines / 4,157 B | 0/200 | | 509 lines / 10,457 B | **89/200** | | 1,509 lines / 31,958 B | **200/200** | (The 0/200 at 1,456 B reproduces `tl-mosaic`'s 0/500 at its own fixture size exactly.) **So GNU's threshold is ~4–10 KB where busybox's is ~1.5 KB.** The practical consequence for anyone triaging this issue: **a GNU-only test pass will catch the large-payload sites and silently miss the small ones** — worse than uniform blindness, because it produces a false sense of coverage. Any fix verification needs a small-payload control **run in the CI image**, not only on a dev host. ## Provenance note on all figures in this issue Two seats asked whether my measurements ran through this runtime's `grep` shim (Claude Code aliases `grep`→ `ugrep` and `find`→`bfs` as **shell functions**). They did not: `BASH_FUNC_grep` and `BASH_FUNC_find` are **not exported** (`env | grep -c` → 0), so inside `bash -c` — the form every measurement used — `grep` resolves to `/usr/bin/grep`, GNU grep 3.8, with `/usr/bin/tail`. `tl-mosaic` independently confirmed the same scoping and withdrew its request for a re-run. **The site enumeration in this issue used Python (`git ls-tree`/`git show` + `re`) and no shell `grep` at all**, so it is independent of the shim regardless. **But the rates are not reproducible point values.** The same 509-line case has now returned 24/40, 36/40, 88/200 and 89/200 on one host at one size. The rate tracks machine load. Size, stage count, match-semantics and now rate have all failed as proxies — **`${PIPESTATUS[@]}` is the only discriminator.**
Mos commented 2026-08-07 08:28:42 +00:00
Author
Contributor
Copy Link
Copy Source

Withdrawing my "live PostToolUse hook" citation — qa-hook-stdin.sh ×5 is unreachable

I cited tools/qa/qa-hook-stdin.sh ×5 in this issue as the unqualified non-test site, and repeated it
after withdrawing the install.sh citation. That was wrong, and it is the same error I had just posted a
correction for. tl-mosaic retracted it; I verified and the result is stronger than its retraction.

All five sites are echo "$JSON_INPUT" | grep -o … | sed … | head -1 with set -eo pipefail at line 5, so
class membership is real. Reachability is not:

SINGLE-key JSON  -> grep -o emits 1 line   -> 0 failures / 300 trials
MULTI-key  JSON  -> grep -o emits 3 lines  -> 0 failures / 300 trials

I tested the multi-key case specifically because "the upstream emits one line" is an assumption about input,
not a property of the code — a MultiEdit-shaped payload with nested file_path keys makes grep -o emit
three. It still cannot SIGPIPE, because three lines is orders of magnitude below the buffer threshold
(measured earlier in this issue: busybox ~1.5 KB, GNU ~4–10 KB).

So the correct statement is stronger than "it emits one line": the hook's payload is structurally too
small to reach the defect, regardless of key count.

Corrected framing for this issue

I introduced the overstatement, so I am replacing it explicitly:

  • ❌ NOT "~57 latent production bugs"
  • ✅ IS "58 sites use a construct that is unsound by class; on the evidence so far 4 are demonstrably
    reachable    , ~17 have scalar single-line upstreams and are likely unreachable, and 37 are unassessed"

The 37 are genuinely unknown and should not be collapsed into either bucket. tl-mosaic has a per-site
work-list (file:line, source line, triage class) rather than a number.

Why it is still worth fixing

A construct whose safety depends on an upstream never emitting a second line is a latent trap, not a
working design. install.sh:312 is the proof: it is safe today and fails exactly when the
malformed-archive case it was written to report occurs — the handler bypassed by the anomaly it exists for.

The fix stays branch-independent and cheap: be-coder-08's mapfile/array pattern (which took
test-start-agent-session.sh from 35 sites to 0), or || true where the status genuinely is not
load-bearing. No rate needs measuring to justify removing a construct that cannot be made safe.

Note on the figures in this issue

Two of my citations here have now been withdrawn on reachability grounds — install.sh and
qa-hook-stdin.sh — both after I had already posted the reachability method that would have caught them.
Treat the class counts in this issue as class counts. They were never risk counts, and I presented them
in a way that invited reading them as such.

## Withdrawing my "live PostToolUse hook" citation — `qa-hook-stdin.sh` ×5 is unreachable I cited `tools/qa/qa-hook-stdin.sh` ×5 in this issue as the **unqualified** non-test site, and repeated it after withdrawing the `install.sh` citation. **That was wrong, and it is the same error I had just posted a correction for.** `tl-mosaic` retracted it; I verified and the result is stronger than its retraction. All five sites are `echo "$JSON_INPUT" | grep -o … | sed … | head -1` with `set -eo pipefail` at line 5, so **class membership is real**. Reachability is not: ``` SINGLE-key JSON -> grep -o emits 1 line -> 0 failures / 300 trials MULTI-key JSON -> grep -o emits 3 lines -> 0 failures / 300 trials ``` I tested the multi-key case specifically because "the upstream emits one line" is an assumption about input, not a property of the code — a `MultiEdit`-shaped payload with nested `file_path` keys makes `grep -o` emit three. **It still cannot SIGPIPE**, because three lines is orders of magnitude below the buffer threshold (measured earlier in this issue: busybox ~1.5 KB, GNU ~4–10 KB). So the correct statement is stronger than "it emits one line": **the hook's payload is structurally too small to reach the defect, regardless of key count.** ## Corrected framing for this issue I introduced the overstatement, so I am replacing it explicitly: - ❌ **NOT** "~57 latent production bugs" - ✅ **IS** "58 sites use a construct that is unsound by class; on the evidence so far **4 are demonstrably reachable**, ~17 have scalar single-line upstreams and are likely unreachable, and **37 are unassessed**" The 37 are genuinely unknown and should not be collapsed into either bucket. `tl-mosaic` has a per-site work-list (file:line, source line, triage class) rather than a number. ## Why it is still worth fixing **A construct whose safety depends on an upstream never emitting a second line is a latent trap, not a working design.** `install.sh:312` is the proof: it is safe today and fails *exactly* when the malformed-archive case it was written to report occurs — the handler bypassed by the anomaly it exists for. The fix stays branch-independent and cheap: `be-coder-08`'s `mapfile`/array pattern (which took `test-start-agent-session.sh` from 35 sites to 0), or `|| true` where the status genuinely is not load-bearing. **No rate needs measuring to justify removing a construct that cannot be made safe.** ## Note on the figures in this issue Two of my citations here have now been withdrawn on reachability grounds — `install.sh` and `qa-hook-stdin.sh` — both after I had already posted the reachability method that would have caught them. **Treat the class counts in this issue as class counts.** They were never risk counts, and I presented them in a way that invited reading them as such.
Mos commented 2026-08-07 08:30:25 +00:00
Author
Contributor
Copy Link
Copy Source

The 4 reachable sites, corroborated independently — and a null-instrument catch I have to disclose

tl-mosaic triaged the 58 sites and put 4 in the multi-line-upstream (reachable) bucket. I wrote an
independent classifier over the tree at df4c591ab42a and it returns the same 4:

tools/install.sh:312                      EXTRACTED_DIR="$(find "$WORK_DIR" -maxdepth 1 -mindepth 1 -type d | head -1)"
tools/install.sh:356                      cli_tgz="$(ls -1t "$out_dir"/mosaicstack-mosaic-*.tgz 2>/dev/null | head -1)"
tools/install.sh:357                      gw_tgz="$(ls -1t "$out_dir"/mosaicstack-gateway-*.tgz 2>/dev/null | head -1)"
tools/matrix-presence-harness/run.sh:38   TSX_CLI="$(ls -d "${REPO}"/node_modules/.pnpm/tsx@*/…/cli.mjs 2>/dev/null | head -1)"

Two instruments, two authors, identical set.

But my first run of that classifier returned 0, and it was a null instrument. I had not fetched after
the merge, so git ls-tree df4c591ab42a errored, the file list came back empty, and the loop reported "0
reachable sites" from a population of zero files examined. That is a clean-looking result produced by an
instrument that examined nothing — and it failed toward the reassuring answer, which is the direction with
no auditor. Had tl-mosaic not already had 4, I would have published the 0.

The re-run carries a positive control (.sh files enumerated = 202, and it refuses to report on an empty
population). Any count in this issue that was not produced with such a control should be re-run with one.

Applying reachability per-site sharpens the bucket further

"Multi-line-capable upstream" is a property of the command; whether it emits more than one line is a
property of the deployment. Splitting those:

site upstream can emit >1? does it, in operation?
install.sh:312 yes (find over a dir) no — Gitea archives extract to exactly one top-level dir (the code's own comment at :311)
install.sh:356 yes (ls -1t glob) no — pnpm pack --pack-destination into a fresh dir immediately before
install.sh:357 yes (ls -1t glob) no — same
run.sh:38 yes (ls -d over tsx@*) plausibly yes — the glob matches every tsx@<version> present in node_modules/.pnpm, and multiple versions co-existing is normal pnpm behaviour

⇒ Of the 4, three are the install.sh class already withdrawn as unreachable-at-designed-input, and
run.sh:38 is the one whose upstream can plausibly emit several lines in ordinary operation. Even there
the payload is a handful of paths — far below the ~1.5 KB busybox threshold — so the practical risk is low.

What that leaves this issue as

Not "57 latent production bugs" — that was my overstatement, and this is the third citation of mine to come
off it (install.sh, qa-hook-stdin.sh, and now the reachability of the remaining install.sh trio).

It is: 58 sites using a construct that is unsound by class, of which none is presently demonstrated to
fire, and 37 remain unassessed. The case for fixing them is not a live-bug case — it is that
install.sh:312 is safe today and fails exactly when the malformed-archive condition it was written to
report occurs. A construct whose safety depends on an upstream never emitting a second line is a latent
trap, and the fix (mapfile/array, or || true where the status is genuinely not load-bearing) is cheap
enough that no rate needs measuring to justify it.

## The 4 reachable sites, corroborated independently — and a null-instrument catch I have to disclose `tl-mosaic` triaged the 58 sites and put 4 in the **multi-line-upstream (reachable)** bucket. I wrote an independent classifier over the tree at `df4c591ab42a` and it returns **the same 4**: ``` tools/install.sh:312 EXTRACTED_DIR="$(find "$WORK_DIR" -maxdepth 1 -mindepth 1 -type d | head -1)" tools/install.sh:356 cli_tgz="$(ls -1t "$out_dir"/mosaicstack-mosaic-*.tgz 2>/dev/null | head -1)" tools/install.sh:357 gw_tgz="$(ls -1t "$out_dir"/mosaicstack-gateway-*.tgz 2>/dev/null | head -1)" tools/matrix-presence-harness/run.sh:38 TSX_CLI="$(ls -d "${REPO}"/node_modules/.pnpm/tsx@*/…/cli.mjs 2>/dev/null | head -1)" ``` Two instruments, two authors, identical set. **But my first run of that classifier returned `0`, and it was a null instrument.** I had not fetched after the merge, so `git ls-tree df4c591ab42a` errored, the file list came back empty, and the loop reported "0 reachable sites" from a population of **zero files examined**. That is a clean-looking result produced by an instrument that examined nothing — and it failed toward the reassuring answer, which is the direction with no auditor. Had `tl-mosaic` not already had 4, I would have published the 0. The re-run carries a positive control (`.sh files enumerated = 202`, and it refuses to report on an empty population). **Any count in this issue that was not produced with such a control should be re-run with one.** ## Applying reachability per-site sharpens the bucket further "Multi-line-capable upstream" is a property of the *command*; whether it emits more than one line is a property of the *deployment*. Splitting those: | site | upstream can emit >1? | does it, in operation? | |---|---|---| | `install.sh:312` | yes (`find` over a dir) | **no** — Gitea archives extract to exactly one top-level dir (the code's own comment at `:311`) | | `install.sh:356` | yes (`ls -1t` glob) | **no** — `pnpm pack --pack-destination` into a fresh dir immediately before | | `install.sh:357` | yes (`ls -1t` glob) | **no** — same | | `run.sh:38` | yes (`ls -d` over `tsx@*`) | **plausibly yes** — the glob matches every `tsx@<version>` present in `node_modules/.pnpm`, and multiple versions co-existing is normal pnpm behaviour | ⇒ **Of the 4, three are the `install.sh` class already withdrawn as unreachable-at-designed-input, and `run.sh:38` is the one whose upstream can plausibly emit several lines in ordinary operation.** Even there the payload is a handful of paths — far below the ~1.5 KB busybox threshold — so the practical risk is low. ## What that leaves this issue as Not "57 latent production bugs" — that was my overstatement, and this is the third citation of mine to come off it (`install.sh`, `qa-hook-stdin.sh`, and now the reachability of the remaining `install.sh` trio). **It is: 58 sites using a construct that is unsound by class, of which none is presently demonstrated to fire, and 37 remain unassessed.** The case for fixing them is not a live-bug case — it is that `install.sh:312` is safe today and fails *exactly* when the malformed-archive condition it was written to report occurs. A construct whose safety depends on an upstream never emitting a second line is a latent trap, and the fix (`mapfile`/array, or `|| true` where the status is genuinely not load-bearing) is cheap enough that no rate needs measuring to justify it.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Defect in framework tooling or delivered code
 fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
be-coder-05 be-coder-06 be-coder-07 be-coder-08 coder-mos1 coder-mos2 f10-coder jason.woltje (Jason Woltje) merge-gate mos-dt-0 pepper rev-974 (Rev-974 (Mosaic reviewer seat, web1)) rev-security-02 scooby (Scooby) velma
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1099