sirens-echo-access-check is on main and not in the image, so the gate it exists to be cannot be run #644

New issue

Closed

opened 2026-08-13 17:48:28 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-13 17:48:28 +00:00

Member

Filed by Angie (ENG, claude seat) against my own merged work. Fix is written and gate-green.

cmd/sirens-echo-access-check is on main. The Dockerfile does not build it:

$ grep -c access-check Dockerfile
0

So the binary exists in source, has tests, and cannot be invoked by the only caller it was written for. Deploy's CI runs against the released image.

How it happened

I caught this before opening #628's pull request and fixed it in a second commit on the same branch. The pull request merged at the first commit. The command landed; the build line did not.

Same shape as #563 and #609 — a branch moving after the state a merge captured — and the same mechanism as #568, where nothing re-evaluates a pull request when its branch or its base changes.

Why it is worth its own issue rather than a quiet follow-up

This is the exact defect the tool was written to prevent, in the tool itself. 628 exists because a bad access policy was only caught after it went live. The fix for that shipped in a state where it cannot run.

It is also the fourth instance today of the class in #618 — built, tested, unreachable — and the only one I introduced after documenting the class. I checked reachability once, fixed it, and then did not check that the fix survived the merge.

Checking a property once is not the same as the property holding. That is the lesson and it is worth the issue it costs.

The fix

Two lines: build it beside the other commands, copy it into the runtime image rather than only the build stage.

**Filed by Angie (ENG, `claude` seat)** against my own merged work. Fix is written and gate-green. `cmd/sirens-echo-access-check` is on `main`. The `Dockerfile` does not build it: ``` $ grep -c access-check Dockerfile 0 ``` So the binary exists in source, has tests, and **cannot be invoked by the only caller it was written for.** Deploy's CI runs against the released image. ## How it happened I caught this before opening https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/628's pull request and fixed it in a second commit on the same branch. The pull request merged at the first commit. The command landed; the build line did not. Same shape as https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/563 and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/609 — a branch moving after the state a merge captured — and the same mechanism as https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/568, where nothing re-evaluates a pull request when its branch or its base changes. ## Why it is worth its own issue rather than a quiet follow-up **This is the exact defect the tool was written to prevent, in the tool itself.** 628 exists because a bad access policy was only caught after it went live. The fix for that shipped in a state where it cannot run. It is also the fourth instance today of the class in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/618 — built, tested, unreachable — and the only one I introduced *after* documenting the class. I checked reachability once, fixed it, and then did not check that the fix survived the merge. **Checking a property once is not the same as the property holding.** That is the lesson and it is worth the issue it costs. ## The fix Two lines: build it beside the other commands, copy it into the runtime image rather than only the build stage.

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-13 17:48:59 +00:00

build: ship the access check, which merged without its build line #646

coilyco-ops closed this issue

2026-08-13 17:50:12 +00:00