amadan
Console: prod-wired canary badge fires from the apex heuristic when the app has no production at all Issue open
Migrated from github.com/carlosframework/platform issue #100, opened 2026-08-07. GitHub issues are closed for this repo; see AGENTS.md, "Work is tracked on amadan, not GitHub".
Still outstanding: The prod-wired canary badge fires from the apex heuristic even when the app has no production route.
---
> Users should only see a warning that a canary is serving everybody when it actually is — the console should not cry wolf about production exposure on an app that has no production.
The "canary in front of everybody" badge fires on an app that has no production anything: no stable route, nothing promoted past canary, and the app's production flag off.
Seen on
carlos.exciting.io, app echo. Its whole route set is two canaries:
| host | channel | environment | |---|---|---| | echo.bab.carlos.exciting.io | canary/first | default | | echo2.bab.carlos.exciting.io | canary/second | default |
echo.bab is badged prod-wired; echo2.bab is not.
Why
Both routes bind default, so if the environment signal in prodWiredCanaryHosts (internal/console/ladder.go:244) were firing, stableEnvs[""] would be true and both would be badged. Only one is, so it is the apex-host signal — and the tie-break is doing all the work. Both hosts have four labels, so it falls through to shortest, and echo.bab.carlos.exciting.io is one character shorter than echo2.bab.carlos.exciting.io.
The gap
The two signals are documented as complements (internal/console/ladder.go:233) — the environment set answers "wired to production GLUE", the apex host answers "in front of production TRAFFIC". The environment signal earns its half: it fires only on a fact, that a stable route exists and binds this environment. The apex signal checks no equivalent fact. prodWiredCanaryHosts receives only []RouteView, so it has no evidence anyone has ever hit the host it elects. It always elects a winner, including when every route in the set is a canary and the app has no production host at all.
The over-flagging note in the same comment ("more flags, never fewer") covers ambiguous cases. This one is not ambiguous — two independent facts say there is no production here — it is uninformed.
Suggested fix
Gate the apex signal on evidence that production exists at all, leaving the environment signal untouched. The fact is already loaded on that page: the signed per-app production flag (release.ProductionFlag, internal/release/production.go), surfaced as Detail.Production.On and already used at internal/console/templates/ladder.html:110 to decide whether promoting to stable needs the extra ceremony. prodWiredCanaryHosts is simply not passed it. Falling back to "any stable route exists" would also work, but the flag is an explicit operator declaration and the better signal.
Not urgent — the badge is visibility only, it restricts nothing.