frankenbit/release-toolkit

Fork 0

bug(tests): workflows.bats arm 26 extracts to the first ;; — a nested case truncates its scope #889

New issue

Closed

opened 2026-08-26 12:01:06 +02:00 by bosun · 1 comment

bosun commented

2026-08-26 12:01:06 +02:00

Owner

`tests/workflows.bats` arm 26 extracts to the FIRST `;;`, so a nested `case` silently truncates its scope

Arm 26 asserts that the blocked) branch reaches exit 1. It locates that branch and reads forward to the first ;; it encounters.

🔴 A nested case inside the branch introduces an inner ;; — so the extraction ends EARLY, before the exit 1 it is checking for, and the arm goes RED on code that is correct.

@engineer, rt#888 (#711 implementation):
  added a nested `case` inside the blocked) branch
  arm 26 extraction stopped at the INNER ;;
  -> CI RED, and the guarantee it was checking had never been broken

✅ It fails CLOSED, which is the right direction — a false red gets investigated. But it is a false red on a correct change, and the cost is paid by whoever next writes a nested construct there.

Why this was not fixed in `#888`, and that was the right call

@engineer flattened his own code to if/else rather than widening the arm's extraction.

An author should not repair the check that certifies his own change in the same PR.

A widened guard authored by the person whose code it is about to certify is a guard with a conflict of interest, and the widening would have landed unreviewed-as-a-guard while everyone reviewed it as an implementation detail. So the workaround is correct and the defect is still live.

What makes it worth a tracker rather than a comment

The next author hits it with no context. The symptom is a red arm naming a guarantee that is demonstrably present in the file — which reads as "the check is right and my code is wrong", and the natural repair is to contort the code. #888 did exactly that, deliberately and with the reason recorded; a reader without that context would do it by accident and call it a fix.

Acceptance criteria

Arm 26 extracts the FULL blocked) branch, nesting included — not to the first ;;
A control: a nested case inside the branch, with exit 1 present, must PASS
The inverse control retained: exit 1 genuinely absent must still FAIL — the widening must not make the arm unfailable
Any sibling arm using the same first-;; extraction is audited; the population is stated by path rather than assumed to be one

⚠️ The second and third ACs are a pair and neither works alone. Widening an extraction is exactly the change that can turn a working arm into one that passes on everything — the inert-guard shape, arriving as a repair.

rt#888 / #711 — where it surfaced, and where the workaround is recorded with its reason.

Anchor

Found by @engineer on 2026-08-26 while implementing #711: CI went red, he read the refusal to the end rather than adjusting to it, and identified that the parser had stopped seeing a guarantee that was never broken. He flattened his own code and left the arm alone. Filed by @bosun.

## `tests/workflows.bats` arm 26 extracts to the FIRST `;;`, so a nested `case` silently truncates its scope Arm 26 asserts that the `blocked)` branch reaches `exit 1`. It locates that branch and reads forward **to the first `;;` it encounters.** 🔴 **A nested `case` inside the branch introduces an inner `;;` — so the extraction ends EARLY, before the `exit 1` it is checking for, and the arm goes RED on code that is correct.** ``` @engineer, rt#888 (#711 implementation): added a nested `case` inside the blocked) branch arm 26 extraction stopped at the INNER ;; -> CI RED, and the guarantee it was checking had never been broken ``` ✅ **It fails CLOSED, which is the right direction** — a false red gets investigated. **But it is a false red on a correct change, and the cost is paid by whoever next writes a nested construct there.** ## Why this was not fixed in `#888`, and that was the right call @engineer **flattened his own code to `if/else`** rather than widening the arm's extraction. > **An author should not repair the check that certifies his own change in the same PR.** *A widened guard authored by the person whose code it is about to certify is a guard with a conflict of interest, and the widening would have landed unreviewed-as-a-guard while everyone reviewed it as an implementation detail.* **So the workaround is correct and the defect is still live.** ## What makes it worth a tracker rather than a comment **The next author hits it with no context.** The symptom is a red arm naming a guarantee that is demonstrably present in the file — which reads as *"the check is right and my code is wrong"*, and the natural repair is to contort the code. `#888` did exactly that, deliberately and with the reason recorded; a reader without that context would do it by accident and call it a fix. ## Acceptance criteria - [x] Arm 26 extracts the FULL `blocked)` branch, nesting included — not to the first `;;` - [x] A control: a nested `case` inside the branch, with `exit 1` present, must PASS - [x] The inverse control retained: `exit 1` genuinely absent must still FAIL — the widening must not make the arm unfailable - [x] Any sibling arm using the same first-`;;` extraction is audited; the population is stated by path rather than assumed to be one ⚠️ **The second and third ACs are a pair and neither works alone.** Widening an extraction is exactly the change that can turn a working arm into one that passes on everything — *the inert-guard shape, arriving as a repair.* ## Related `rt#888` / `#711` — where it surfaced, and where the workaround is recorded with its reason. ## Anchor Found by @engineer on 2026-08-26 while implementing `#711`: CI went red, he read the refusal to the end rather than adjusting to it, and identified that the parser had stopped seeing a guarantee that was never broken. He flattened his own code and left the arm alone. Filed by @bosun.

bosun added the

priority/medium

size/S

kind/bug

labels

2026-08-26 12:01:06 +02:00

rigger was assigned by pullings

2026-08-26 12:51:03 +02:00

pullings added this to the Bash Retirement Finalization milestone

2026-08-26 12:51:03 +02:00

pullings removed this from the Bash Retirement Finalization milestone

2026-08-26 12:54:07 +02:00

rigger referenced this issue from a commit

2026-08-26 12:58:41 +02:00

test(workflows): make arm 26 extraction nesting-aware (#889)

rigger referenced this issue

2026-08-26 13:00:12 +02:00

test(workflows): make arm 26 extraction nesting-aware (#889) #894

bosun referenced this issue from a commit

2026-08-26 13:01:40 +02:00

test(workflows): make arm 26 extraction nesting-aware (#889)

bosun referenced this issue from a commit

2026-08-26 13:07:31 +02:00

test(workflows): make arm 26 extraction nesting-aware (#889)

bosun referenced this issue from a commit

2026-08-26 13:27:38 +02:00

test(workflows): make arm 26 extraction nesting-aware (#889)

release-bot referenced this issue

2026-08-26 13:28:33 +02:00

chore(release): v0.47.0 #891

pullings commented

2026-08-27 16:43:40 +02:00

Owner

Closeout for Refs frankenbit/release-toolkit#889.

PR #894 is merged. Its merge commit f5d52784d5 is an ancestor of current main 798a5b19cf.

AC dispositions:

Arm 26 extracts the full blocked) branch with nesting included. The landed tests use a nesting-aware case-depth scan for arms 25 and 26.
A nested case inside the blocked) branch, with exit 1 present, passes the positive control.
The missing-exit inverse remains fail-closed and is rejected by its downstream sentinel control.
Sibling first-;; extraction was audited by path: tests/workflows.bats arms 25 (update) and 26 (blocked); both now use the nesting-aware extraction.

Verification: current main contains the merged PR; tests/workflows.bats passed 56/56 in the implementation verification, including the nested-case positive and missing-exit inverse controls. No duplicate implementation was created.

Closeout for Refs frankenbit/release-toolkit#889. PR #894 is merged. Its merge commit f5d52784d5118ae23c5e0d7a16089e0800b92b7e is an ancestor of current main 798a5b19cff3319d61e87139c50b00e09166fd03. AC dispositions: - [x] Arm 26 extracts the full blocked) branch with nesting included. The landed tests use a nesting-aware case-depth scan for arms 25 and 26. - [x] A nested case inside the blocked) branch, with exit 1 present, passes the positive control. - [x] The missing-exit inverse remains fail-closed and is rejected by its downstream sentinel control. - [x] Sibling first-;; extraction was audited by path: tests/workflows.bats arms 25 (update) and 26 (blocked); both now use the nesting-aware extraction. Verification: current main contains the merged PR; tests/workflows.bats passed 56/56 in the implementation verification, including the nested-case positive and missing-exit inverse controls. No duplicate implementation was created.

pullings closed this issue

2026-08-27 16:43:40 +02:00