finding: coily upgrade silent no-op on hosts stranded on the deprecated umbrella tap #153

Open
opened 2026-05-28 21:16:39 +00:00 by coilysiren · 0 comments
Owner

Observation

(incident, 2026-05-28) A Mac host had coily v1.9.5 installed from the deprecated umbrella tap coilysiren/tap (GitHub coilysiren/homebrew-tap). The release pipeline now publishes to the per-repo Forgejo tap coilysiren/coily, currently v2.49.1. coily upgrade reported coilysiren/tap/coily 1.9.5 already installed and exited 0, leaving the operator on 1.9.5 with no signal that a newer formula existed elsewhere. It was discovered only because a v2 verb (coily ops forgejo issue) was missing and a human flagged "your coily is very old."

Failure mechanism

v2's coily upgrade resolves the qualified formula name from brew tap and prefers coilysiren/coily/coily over coilysiren/tap/coily only when both are installed. On a host that has only the umbrella tap, it resolves to coilysiren/tap/coily and runs brew upgrade coilysiren/tap/coily. That formula is frozen at 1.9.5 (releases moved to Forgejo), so brew reports "already installed" and exits 0. Nothing compares the installed origin against the canonical Forgejo per-repo tap, so the staleness is invisible.

Note: the host was actually running v1.9.5, whose coily upgrade hardcoded the umbrella tap outright. v2 improved this to a tap-preference resolution, but the only-umbrella-tap case still silently no-ops.

Why it is a finding (opaque failure)

Per coily-meta 6.2.7, this is a low-priority opaque failure where the opaqueness is itself the bug. coily upgrade succeeds (exit 0) while doing nothing useful and emits no hint that the canonical tap is un-added. It rhymes with the 4.4 anti-signal ("the error names the fix but does not apply it"), except here there is no error at all.

Fix shape (candidates)

  • coily upgrade detects when the resolved formula is the umbrella tap AND the per-repo Forgejo tap coilysiren/coily is not installed, then either (a) prints the exact brew tap coilysiren/coily <forgejo-url> migration command plus the available version diff, or (b) performs the one-time brew tap itself before upgrading.
  • Alternatively a coily doctor check that flags "installed from deprecated tap, canonical tap not present."
  • Either way: never exit 0 silently when a newer formula exists on an un-added canonical tap.

Recovery that worked this session

brew tap coilysiren/coily https://forgejo.coilysiren.me/coilysiren/coily --allow-untapped, then brew upgrade coilysiren/coily/coily --allow-untapped (both via coily pkg brew), then coily setup. Took the host 1.9.5 -> 2.49.1. The old umbrella tap was left tapped since it may provide other formulae.

## Observation (incident, 2026-05-28) A Mac host had coily v1.9.5 installed from the deprecated umbrella tap `coilysiren/tap` (GitHub `coilysiren/homebrew-tap`). The release pipeline now publishes to the per-repo Forgejo tap `coilysiren/coily`, currently v2.49.1. `coily upgrade` reported `coilysiren/tap/coily 1.9.5 already installed` and exited 0, leaving the operator on 1.9.5 with no signal that a newer formula existed elsewhere. It was discovered only because a v2 verb (`coily ops forgejo issue`) was missing and a human flagged "your coily is very old." ## Failure mechanism v2's `coily upgrade` resolves the qualified formula name from `brew tap` and prefers `coilysiren/coily/coily` over `coilysiren/tap/coily` only when both are installed. On a host that has only the umbrella tap, it resolves to `coilysiren/tap/coily` and runs `brew upgrade coilysiren/tap/coily`. That formula is frozen at 1.9.5 (releases moved to Forgejo), so brew reports "already installed" and exits 0. Nothing compares the installed origin against the canonical Forgejo per-repo tap, so the staleness is invisible. Note: the host was actually running v1.9.5, whose `coily upgrade` hardcoded the umbrella tap outright. v2 improved this to a tap-preference resolution, but the only-umbrella-tap case still silently no-ops. ## Why it is a finding (opaque failure) Per coily-meta 6.2.7, this is a low-priority opaque failure where the opaqueness is itself the bug. `coily upgrade` succeeds (exit 0) while doing nothing useful and emits no hint that the canonical tap is un-added. It rhymes with the 4.4 anti-signal ("the error names the fix but does not apply it"), except here there is no error at all. ## Fix shape (candidates) - `coily upgrade` detects when the resolved formula is the umbrella tap AND the per-repo Forgejo tap `coilysiren/coily` is not installed, then either (a) prints the exact `brew tap coilysiren/coily <forgejo-url>` migration command plus the available version diff, or (b) performs the one-time `brew tap` itself before upgrading. - Alternatively a `coily doctor` check that flags "installed from deprecated tap, canonical tap not present." - Either way: never exit 0 silently when a newer formula exists on an un-added canonical tap. ## Recovery that worked this session `brew tap coilysiren/coily https://forgejo.coilysiren.me/coilysiren/coily --allow-untapped`, then `brew upgrade coilysiren/coily/coily --allow-untapped` (both via `coily pkg brew`), then `coily setup`. Took the host 1.9.5 -> 2.49.1. The old umbrella tap was left tapped since it may provide other formulae.
coilysiren added
P2
and removed
P1
labels 2026-05-31 06:59:40 +00:00
Sign in to join this conversation.
No labels
P0
P1
P2
P3
P4
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
coilyco-bridge/coily#153
No description provided.