Skip to content

v1.9.3 — a blank KNAG_ENV is unknown, never local

Choose a tag to compare

@danjamk danjamk released this 06 Sep 12:08
· 7 commits to main since this release
74d9a85

A deploy that skipped the --var flags believed it was running on a laptop, and a laptop is where knag prints login codes to the log.

Fixed

  • A blank KNAG_ENV read as local (#248). The var is baked at deploy by --var, which only the Makefile and the two deploy workflows pass; a plain wrangler deploy shipped the committed default, which was "". Every reader spelled the fallback KNAG_ENV || "local", so such a deploy would take sendMail's local branch — and that branch writes the six-digit login code into the log, the one thing ADR-008 §9 says must never reach a real deployment's observability. It also reported local at /health, the field that exists so a deploy to the wrong environment can be told from one that failed.

    Blank now fails closed: envName() answers unknown, the code is withheld, and the misconfiguration is logged as one. local became a value the local entry points pass out loud — pnpm dev and scripts/dev-lan.sh both send --var KNAG_ENV:local.

    Nothing in dev or prod was affected. Both workflows bake the var, so neither has ever shipped a blank one. It was reachable only by a deploy nothing performs today — which is exactly what a Deploy to Cloudflare button would perform (#247).

Changed

  • The committed defaults name an environment instead of nothing: selfhost at the top level, prod under env.prod.
  • selfhost wears the prod tile and no subject-line tag. Both marks exist to tell two installs apart, and a self-hosted knag is somebody's only one. local keeps the mark — dev-lan on a phone sits beside prod on the same home screen.

Full changelog: v1.9.2...v1.9.3