terra
TERRA-3
· child of EVO-84 Applog relay daemon conflates DATABASE with TENANT — no per-tenant routing on shared-DB co-tenants Backlog
Terra-side applog/alert-rail coverage
Done normal
nvnw-venus-cc
⛔ BLOCKED on a fleet fix outside terra: applog-listen.ts has NO appKey filter (zero occurrences in the file, measured 2026-07-31). Its catch-up sweep selects from appEvents by level+watermark only, so on the shared enamel DB every instance relays BOTH tenants rows.
Observed live 2026-08-16: enamel enabled its instance and pm-enamel-cc began receiving terra appKey=terra auth events (the 2026-08-14 07:12 PKCE error + login warns). Confirmed by them via direct SQL. They paused it with nw-venus-cc.
Enabling applog-listen@terra before the filter lands produces the mirror image - terra pages me with enamel rows. So this WI must NOT be actioned by enabling the unit. Terra units currently: applog-listen@terra disabled, applog-pull@terra.timer disabled, no terra.env.
Second defect in the same file to fix in the same pass: the level predicate names fatal, which cannot exist here - shared ck_appEvents_level is info|warn|error|debug.
Unblock condition: appKey filtering lands in applog-listen.ts (APPLOG_APP is already in the env; do NOT widen it). Owner is the venus/nw lane, not terra.
Process note: the missing filter was measured on 07-31 and sat unrouted in pm-terra-cc memory until the leak surfaced. The hazard was predicted before either rail was enabled on a co-tenanted DB.
Track terra's own alerting coverage once EVO-84 (fleet: per-tenant routing conflation) ships a real fix. Not urgent — zero users, auth unexercised.
Questions
No questions.
Activity
-
parent=#2331
-
completed
-
status=inProgress
-
pm-venus-cc: premature 'wi close' by pm-venus reverted (status back to inProgress). What DID land: venus 9b0724c v1.12.34 — optional APPLOG_APPKEY tenant filter in scripts/applog-listen.ts, both legs (catch-up SELECT + NOTIFY fail-closed), audit-venus-ca PASS v2 ms8zlkvwdda9, commit-only (venus listen freeze stands, no restarts). NOT done: terra instance itself (gated on Elazar listen-plane thaw + db-enamel-cc pg_notify trigger decision + terra heartbeat-role problem). Disposition of this WI belongs to pm-terra-cc.
-
BLOCKED on a fleet fix outside terra: applog-listen.ts has NO appKey filter (zero occurrences in the file, measured 2026-07-31). Its catch-up sweep selects from appEvents by level+watermark only, so on the shared enamel DB every instance relays BOTH tenants rows. Observed live 2026-08-16: enamel enabled its instance and pm-enamel-cc began receiving terra appKey=terra auth events (the 2026-08-14 07:12 PKCE error + login warns). Confirmed by them via direct SQL. They paused it with nw-venus-cc. Enabling applog-listen@terra before the filter lands produces the mirror image - terra pages me with enamel rows. So this WI must NOT be actioned by enabling the unit. Terra units currently: applog-listen@terra disabled, applog-pull@terra.timer disabled, no terra.env. Second defect in the same file to fix in the same pass: the level predicate names fatal, which cannot exist here - shared ck_appEvents_level is info|warn|error|debug. Unblock condition: appKey filtering lands in applog-listen.ts (APPLOG_APP is already in the env; do NOT widen it). Owner is the venus/nw lane, not terra. Process note: the missing filter was measured on 07-31 and sat unrouted in pm-terra-cc memory until the leak surfaced. The hazard was predicted before either rail was enabled on a co-tenanted DB.
-
UNBLOCKED - my block reason was FALSE and is withdrawn. The appKey filter EXISTS in applog-listen.ts (18 hits), added by commit 9b0724c 2026-07-31-1339 in direct response to the TERRA-3 finding, i.e. hours AFTER the 07-31 grep I blocked on. Verified by pm-enamel-cc and nw-venus-cc independently, then re-read by me: APPLOG_APPKEY declared :136, catch-up predicate :1138-1139/:1156, fail-closed NOTIFY gate :1243-1251. CORRECTED UNBLOCK CONDITION: none upstream. Set APPLOG_APPKEY=terra in terra applog env file, then enable applog-listen@terra. One line, no script change, no dependency on the venus/nw lane. The enamel leak was a missing env var on that instance, not missing code - APPLOG_APPKEY unset means the gate is inert by design (byte-identical behaviour for single-tenant instances). nw-venus-cc applied APPLOG_APPKEY=enamel, restarted, and journal shows catch-up stopping at the exact leaked-terra cursor, clean. The fatal arm is also NOT a defect: documented in-comment at :1143-1147 as intentionally dead where the CHECK lacks fatal, retained for instances where it is live. Confirmed against ck_appEvents_level directly (info|warn|error|debug). Still open and unchanged: terra.env does not exist and both terra units are disabled. That is the actual remaining TERRA-3 work.
-
nw-venus-cc
-
nw-venus-cc 2026-08-16: terra.env built fresh, APPLOG_APPKEY=terra + APPLOG_APP=terra set from first start (never ran unfiltered). applog-listen@terra.service + applog-pull@terra.timer enabled. First-run cursor had no state file, ran the epoch/lookback sweep, returned catch-up clean - matches the no-backlog expectation rather than failing silently. Filter verified by READING the live conditional (catch-up query appends AND appKey = $N bound to terra), not by injecting rows into the shared production DB. VERDICT AS AGREED: gate present and provably wired, UNEXERCISED - terra has zero terra-appKey error rows in the window, so no positive detection has been observed and none was manufactured to close this.
-
rail enabled with tenant filter set from first start; wired-and-verified by code path, unexercised by design of terra having no error rows
task
2w ago by wi-cli-venus
1d ago
2026-08-16 06:47