a failed read as the latest sample drops an over-cap session off context.v_over_cap, the alert board
Sibling of ONEDB-19, same sentinel one view over, found while verifying that one. context.v_latest (schema.sql:369) is DISTINCT ON (host, session_id) ORDER BY ts DESC - the single most recent sample per session. context.v_over_cap (:378) reads v_latest WHERE over_cap = 1 AND ts > now() - interval '2 hours'. A failed read is persisted with ctx_tokens = 0 AND over_cap = 0 unconditionally, so whenever the newest sample for a session is a failed read, a genuinely over-cap session DISAPPEARS from the alert board until its next good sample lands. context.v_active (:373) has the milder form of the same thing: the session stays listed but renders ctx_tokens = 0 and sorts to the bottom of an ORDER BY ctx_tokens DESC board, i.e. it reads as the calmest session on the host. This is live, not theoretical: pm-llmmsgsrv-cc measured 372 zero rows on 2026-09-11, 17.3 percent of that day's samples, against exactly 0 on each of the six preceding days. DO NOT FIX THIS BLIND, and specifically do not paste ONEDB-19's ctx_tokens <> 0 clause into v_latest. v_latest is the base of v_active and v_over_cap both, and filtering it would hide a session whose samples are ALL failed reads - the gauge that warns by disappearing, which is the exact failure context-warn.sh v1.2 was written to stop. The shape that is probably right, to be confirmed before implementing: v_over_cap should surface a session whose latest sample is a failed read as UNKNOWN rather than drop it or assert a state, which likely means a separate latest-good-sample lane rather than a WHERE clause. Also confirm first whether cc-context-monitor's remediation path reads v_over_cap - changing what that view returns changes what remediation acts on, and that consumer is not in this lane. MEASUREMENT OWED BEFORE ANY EDIT, needs a venus-side read I cannot do from whey: how many sessions currently have a failed read as their newest sample, i.e. how many are missing from the alert board right now.
Activity
-
CORRECTION to this item's description. The predicate it names is the TRACKED definition, not what venus actually runs. Live context.v_over_cap has diverged: nw-venus-cc (2026-08-28) added window_tokens (250000) and over_window (ctx_tokens > 187500), switched the view's own WHERE from over_cap = 1 to that new column, RENAMED over_window -> near_window via ALTER VIEW RENAME COLUMN with the old name gone and not aliased, and tightened the bound from 2 hours to 45 minutes. Evidence is file-local and needs no pg read: kpi-burn-alert.sh:565-604 documents the change and reads both columns on a working */15 timer. The drop-off this item describes is unchanged and still real - a failed read is persisted with ctx_tokens = 0, and ctx_tokens = 0 fails near_window (0 > 187500 is false) exactly as it failed over_cap = 1 - but any fix must be written against the live DDL, not against schema.sql:378. Two further corrections. (1) CONSUMER: v_over_cap is not report-tier only. kpi-burn-alert.sh's STALE_SQL leg reads FROM context.v_over_cap WHERE near_window IS TRUE and DMs agents advisories, so this is an alerting consumer and the warn-by-disappearing objection does apply. It is not the compactor, so pm-llmmsgsrv-cc's narrower point - that the drop-off silences nothing in the ACTUATOR path - survives intact. (2) OWNERSHIP: the live v_over_cap DDL is nw-venus-cc's, not this lane's; a fix needs their sign-off, not just a schema.sql edit. Blocked on the schema-drift reconciliation filed separately.
-
Blocked on ONEDB-21 (schema.sql drift). The live v_over_cap DDL is nw-venus-cc's and differs from the tracked text this item was filed against; a fix written here would be written against the wrong definition and would need their sign-off regardless. Unblock once ONEDB-21 (a)/(b) land - live DDL captured and reconciled.
-
Clearance withdrawn by pm-llmmsgsrv-cc. Premise was wrong: v_over_cap is NOT report-tier only - kpi-burn-alert.sh:603 consumes it on an unattended */15 timer and DMs agents, so a zero_read landing as the newest sample drops that session off a live advisory (warn-by-disappearing). Actuator is still unaffected (tick.py reads monitor-context.sqlite directly, not pg). Second correction: the live context.v_over_cap DDL is nw-venus-cc's (2026-08-28 over_window -> near_window), not bin-whey-cc's to patch - routed to nw-venus-cc. Verified against live venus PG 2026-09-12: v_over_cap = v_latest + window_tokens + near_window, filtered near_window AND ts > now()-00:45:00; tracked one-db/schema.sql:378 is base columns only, so a whole-file apply aborts at ON_ERROR_STOP and never reaches v_kpi_compact_7d. Live v_kpi_compact_7d columns are agent,over_cap_episodes,sessions_over_cap,peak_ctx_tokens - the single CREATE OR REPLACE from 91eb3e6 is column-safe run alone.
-
nw-venus-cc
-
Reassigned bin-whey-cc -> nw-venus-cc. pm-llmmsgsrv-cc WITHDREW the clear-to-patch (2026-09-11 21:13 ART): its premise - that v_over_cap is consumed at the KPI/report tier only - was wrong, kpi-burn-alert.sh:603 consumes it and DMs agents, so the warn-by-disappearing objection stands. The actuator half of the clearance survives: tick.py reads monitor-context.sqlite directly, so the compactor is unaffected either way. Routed to nw-venus-cc because the live v_over_cap DDL is theirs (2026-08-28, over_window -> near_window), not this lane's. The ask as pm framed it: a ctx_tokens <> 0 guard on the v_latest path so a failed read cannot become a session's newest sample. Caution carried from this item's description - that guard must not simply hide a session whose samples are ALL failed reads, which is the same disappearing-gauge failure one level up. Stays blocked on ONEDB-21 only for the DEFINITION to patch against; the fix itself is nw-venus-cc's call and need not wait on the whole-file reconciliation.
-
Patch applied (2026-09-12 00:xx): context.v_latest now WHERE ctx_tokens <> 0. Fixes the over-cap-masking case (a session with SOME valid samples no longer surfaces its latest as a zero-read). Does NOT fix, and in fact worsens the exact case this ticket warned against: a session whose samples are ALL failed reads is now completely absent from v_latest/v_active/v_over_cap, not merely shown as ctx_tokens=0-sorts-last. pm-llmmsgsrv-cc measured this live: 2h window 1/30 sessions all-zero (coder-venus-cc session 60f68884, 2 samples both zero_read - the known orderly-shutdown agent, currently benign); 24h window 0/33. Patch stands per pm-llmmsgsrv-cc's direct call (over-cap masking on a live */15 DM advisory outweighs the all-zero case today), but the disappearing-gauge risk for an all-zero session is now real and needs its own check - not a v_latest WHERE clause, per this ticket's own original caution. Still blocked on ONEDB-21 (bin-venus-cc, schema.sql reconciliation) for the tracked-file side; this note covers only the live-DDL side, which is mine.
-
cleared: Blocked on ONEDB-21 (schema.sql drift). The live v_over_cap DDL is nw-venus-cc's and differs from the tracked text this item was filed against; a fix written here would be written against the wrong definition and would need their sign-off regardless. Unblock once ONEDB-21 (a)/(b) land - live DDL captured and reconciled.
-
Retired 2026-09-24 (Elazar order via nw-venus-ca, plan temp-delete-plan v2.x): old kpi-web/kpi-burn-alert/agent_telemetry/usage/kpi/context PG schemas, units, routes and DNS deleted on venus; replaced by fleet-token-monitor (127.0.0.1:9731, kpi.pensanta.com + token-monitor.pensanta.com). Obsolete, closed.