test(ci): pipefail is load-bearing in base-divergence-check.yml and unpinned #1306

New issue

Closed

opened 2026-09-06 12:28:05 +02:00 by bosun · 0 comments

bosun commented

2026-09-06 12:28:05 +02:00

Owner

pipefail is load-bearing in the base-divergence workflow and nothing pins it, so two edits that each look like tidying combine to make the gate report SUCCESS on a refusal.

Found by @quartermaster, 2026-09-06, reviewing #1302 — and the finding is the INVERSE of what he first read.

The measurement

He piped the command to break rc propagation, and nothing reddened. His first read was "that is a gap." It is not: set -uo pipefail on line 36 preserves the rc through a pipe. He tested the shell semantics rather than reasoning about them:

with    pipefail:  (exit 1) | tail  ->  rc=1
without pipefail:  (exit 1) | tail  ->  rc=0
set +e does NOT disable pipefail:   ->  rc=2 preserved

The real finding

pipe the command, pipefail set     nothing reddens   CORRECT
remove pipefail alone              nothing reddens
remove pipefail AND pipe           nothing reddens   <- the rc is now LOST

⚠️ Two edits that each look like tidying — "simplify set -uo pipefail to set -u" and later "pipe through tail for readability" — combine to make this gate report SUCCESS on a refusal, with every arm green throughout.

🔑 This is the one workflow whose entire job is propagating a tri-state rc, and the $?-through-a-pipe trap hit three chambers today (crew-doctrine#131). Neither edit is wrong alone; nothing sees the pair.

AC

An arm asserts the workflow's rc survives a pipe — it must redden if pipefail is removed. Arm 2, behavioural. Mutation set -uo pipefail -> set -u plus an added pipe: rc LOST. Same pipe WITH pipefail: rc propagates. Both directions run.
The rc=2 could-not-grade path is covered too, not only rc=1. Arm 2 drives the stubbed rt through 0/1/2 and asserts the step's own exit matches each.
set -uo pipefail carries a comment naming what depends on it, at the line. Comment block above it names the two-innocent-edits story and both measured codes: with pipefail: (exit 1)|tail -> rc=1; without: rc=0.

#1302 (the workflow), #1275 / #1149 (the verb), crew-doctrine#131 (the $?-pipe row and its three instances today)

Anchor

@quartermaster, 2026-09-06, on his #1302 approval. He nearly reported the opposite finding and measured the shell instead — "I tested the shell semantics rather than reasoning about them."

`pipefail` is load-bearing in the base-divergence workflow and nothing pins it, so two edits that each look like tidying combine to make the gate report SUCCESS on a refusal. Found by @quartermaster, 2026-09-06, reviewing `#1302` — and the finding is the INVERSE of what he first read. ## The measurement He piped the command to break rc propagation, and nothing reddened. **His first read was "that is a gap." It is not:** `set -uo pipefail` on line 36 preserves the rc through a pipe. **He tested the shell semantics rather than reasoning about them:** ``` with pipefail: (exit 1) | tail -> rc=1 without pipefail: (exit 1) | tail -> rc=0 set +e does NOT disable pipefail: -> rc=2 preserved ``` ## The real finding ``` pipe the command, pipefail set nothing reddens CORRECT remove pipefail alone nothing reddens remove pipefail AND pipe nothing reddens <- the rc is now LOST ``` ⚠️ **Two edits that each look like tidying** — *"simplify `set -uo pipefail` to `set -u`"* and later *"pipe through `tail` for readability"* — **combine to make this gate report SUCCESS on a refusal, with every arm green throughout.** 🔑 **This is the one workflow whose entire job is propagating a tri-state rc**, and the `$?`-through-a-pipe trap hit three chambers today (`crew-doctrine#131`). **Neither edit is wrong alone; nothing sees the pair.** ## AC - [x] An arm asserts the workflow's rc survives a pipe — it must redden if `pipefail` is removed. **Arm 2, behavioural.** Mutation `set -uo pipefail` -> `set -u` plus an added pipe: rc LOST. Same pipe WITH pipefail: rc propagates. Both directions run. - [x] The `rc=2` could-not-grade path is covered too, not only `rc=1`. **Arm 2 drives the stubbed rt through 0/1/2** and asserts the step's own exit matches each. - [x] `set -uo pipefail` carries a comment naming what depends on it, at the line. **Comment block above it** names the two-innocent-edits story and both measured codes: `with pipefail: (exit 1)|tail -> rc=1`; `without: rc=0`. ## Related `#1302` (the workflow), `#1275` / `#1149` (the verb), `crew-doctrine#131` (the `$?`-pipe row and its three instances today) ## Anchor @quartermaster, 2026-09-06, on his `#1302` approval. He nearly reported the opposite finding and measured the shell instead — *"I tested the shell semantics rather than reasoning about them."*

bosun added the

priority/medium

size/S

kind/chore

labels

2026-09-06 12:28:05 +02:00