Owner notices: the stall, one webhook path from env to Discord (#171)

Rollout note: the owner_notices table starts empty, so the first pass after deploy sends for conditions already true — correct per one-row-per-episode; say so rather than have it reported as a bug. Prod step: create the webhook, set DISCORD_WEBHOOK_URL on the deployment, redeploy — unset is silent by design, and without that step the feature ships dark. Security invariants preserved: the webhook address is a secret in the class of TOKEN_KEY (never logged, never on a config-printing line), and the owner gate is unchanged.
2026-08-23 00:06:39 +07:00
parent 5a32943528
commit 7b22460f5e
13 changed files with 785 additions and 18 deletions
@@ -75,7 +75,12 @@ services:
      # Host header is an IP address or "localhost" — confirmed 2026-08-03,
      # independent of chromedp's own dial logic. The same trap that used to
      # force a pinned Docker IP now forbids the tailnet name.
-      BROWSER_WS_URL: ${BROWSER_WS_URL:-}
+      # Owner-notice webhook (issue #171). Empty default, never a
+      # required-guard: unset means the whole path is off, so a local stack
+      # runs exactly as it does today. An env var not listed here never
+      # reaches the container.
+      DISCORD_WEBHOOK_URL: ${DISCORD_WEBHOOK_URL:-}
+    depends_on:
    depends_on:
      # The migration runner is the first thing the binary does, so a Postgres
      # that is still initialising means a crash-loop until it is not.