From bff4dec49ae063dec37c9ecf4e92763d3aa7c62a Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 21 Aug 2026 15:49:35 +1000 Subject: [PATCH] Document the env keys that were missing from .env.example This file says "every key, no values" at the top and was not that, which cost real time twice on lin001 in one day. - CUBEJS_DB_* was absent entirely, while ai-compose.yml states that Cube's database settings come from api.env. Deploying Cube meant reconstructing what it needed from compose comments and db/003_roles.sql. Added, with the pg-ai.env names its credentials come from, and a note that Phase 4 turns the block into an mssql connection against imh. Also recorded NEGATIVELY: not CUBEJS_EXT_DB_*. Cube v1 refuses Postgres as an external pre-aggregation store, so someone reading the older compose file will otherwise try to supply keys for a setting that must not exist. - NO_LLM_STUB, which is new and defaults to false here for the same reason it defaults to false in config.py. - The Langfuse keys were listed but not explained, and every way of getting them wrong is SILENT: absent -> _langfuse() returns None, every question untraced mismatched pair -> a client is built, Langfuse rejects it, and main.py swallows the exception by design Neither logs anything, in an answer path that is deliberately built never to break on observability. The symptom is identical - no traces - so correcting one cause while the other is still present looks like no progress at all. That is exactly what happened: a placeholder secret was pasted alongside a public key from a different pair, and the fix looked like it had not worked. So the file now says: they are PROJECT keys from the UI, not the server's own SALT/NEXTAUTH_SECRET in langfuse.env; they must be a matched pair; the secret is shown once and stored hashed, so it cannot be read back; and traces must be confirmed as ARRIVING rather than inferred from config. No secrets here, including the masked tail of a real key - the example suffix is invented. The Langfuse fix itself is not in this commit and cannot be: it was two lines in ~/ai/api.env, which .gitignore excludes on purpose. Co-Authored-By: Claude Opus 5 --- .env.example | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/.env.example b/.env.example index 0629fc8..ca68d5e 100644 --- a/.env.example +++ b/.env.example @@ -35,6 +35,13 @@ CHAT_DEPLOYMENT= # flagship — final prose only CHEAP_DEPLOYMENT= # nano/mini — classifier, entities, tool selection EMBED_DEPLOYMENT= # text-embedding-3-small +# --- no-LLM stub mode -------------------------------------------------------- +# OFF for anything real. With it on, no model is called: the class comes from +# the caller instead of the classifier and the prose is a fixed placeholder. +# Every answer carries stub_mode: true and a banner. See api/stub.py for what +# it proves and what it does not. +NO_LLM_STUB=false + # --- behaviour --------------------------------------------------------------- CLASSIFIER_CONFIDENCE_THRESHOLD=0.7 SITE_TIMEZONE=Australia/Sydney # storage UTC; convert once, in Cube @@ -46,7 +53,38 @@ MAX_OUTPUT_TOKENS=1200 CUBEJS_API_SECRET= CUBEJS_API_URL=http://cube:4000/cubejs-api/v1 +# The upstream source Cube reads. ai-compose.yml says these come from this +# file, and this file did not list them - so the first person to deploy Cube +# had to work out from the compose comments and db/003_roles.sql what the +# service actually needed. While USE_FIXTURES=true the fixtures live in pg-ai, +# so this points at pg-ai with the cube_rw credentials from pg-ai.env. +# At Phase 4 the whole block becomes CUBEJS_DB_TYPE=mssql against imh. +CUBEJS_DB_TYPE=postgres +CUBEJS_DB_HOST=pg-ai +CUBEJS_DB_PORT=5432 +CUBEJS_DB_NAME=plant +CUBEJS_DB_USER=cube_rw # CUBE_DB_USER in pg-ai.env +CUBEJS_DB_PASS= # CUBE_DB_PASSWORD in pg-ai.env + +# NOT CUBEJS_EXT_DB_*. Cube v1 will not use Postgres as an external +# pre-aggregation store; cubestore does that job and needs no keys here. +# See the note above the cube service in compose/ai-compose.yml. + # --- Langfuse ---------------------------------------------------------------- +# PROJECT keys, created in the Langfuse UI - not the server's own secrets +# (SALT, NEXTAUTH_SECRET), which live in langfuse.env and are a different +# thing. The two must be a MATCHED PAIR from the same key: a public key from +# one pair with a secret from another authenticates as neither. +# +# Langfuse shows the secret ONCE, at creation, and stores only a hash - the +# database keeps a masked form (sk-lf-...abcd) and nothing can recover it. If +# it is lost, generate a new pair; there is no way to read the old one back. +# +# Getting this wrong is silent in both directions. Keys absent -> _langfuse() +# returns None and every question is simply untraced. Keys present but wrong -> +# a client is built, Langfuse rejects it, and main.py swallows the exception on +# purpose, because observability must never break the answer path. Neither case +# logs anything. Confirm traces are ARRIVING; do not infer it from config. LANGFUSE_HOST=http://langfuse:3000 LANGFUSE_PUBLIC_KEY= LANGFUSE_SECRET_KEY=