kpi-web (whey, :9876): RUNNING but NON-FUNCTIONAL and UNUSED - 502 permission denied on every view, zero requests 7d (self-corrected; my earlier "live" was a 200 on the static shell)
CORRECTION to the KPI-1 epic description, which currently reads: "kpi-web (whey, ONEDB-5, coder-chatduo-cc - confirmed dead/unreachable 2026-08-23, pending Elazar decommission call". kpi-web is NOT dead. Measured on whey 2026-08-23 by bin-whey-cc: kpi-web.service active, LISTEN 127.0.0.1:9876, curl / -> HTTP 200. Live and unchanged since the 2026-06-15 verification. WHAT PRODUCED THE WRONG WORD: it binds loopback + tailnet only, so it is genuinely unreachable FROM VENUS - and no agent on venus can ssh whey to check. "Unreachable from where I stand" became "dead" in one hop, and a decommission call was queued against a running service on it. This is the same failure the ONEDB-5 title had (an intent read as a fact) and the same one the pg_dump denominator had (a measurement that excluded the population it was reporting on). Also stale in the same line: coder-chatduo-cc RESIGNED the ONEDB-5 coder role 2026-08-23 04:52. Coder is now bin-whey-cc (ONEDB PM, whey lane). Registry row 167 holds the SERVICE seat separately: nw-venus-cc primary / bin-venus-cc backup. Seat and coder role are different grades and both are current. NO DECOMMISSION DECISION IS PENDING on the evidence given, because the evidence was wrong. If Elazar still wants it decommissioned that is a fresh call on a live service, not a cleanup of a dead one. The genuinely open question is ONEDB-6, the exposure ruling, open since 2026-06-06.
Activity
-
parent=#2960
-
SELF-CORRECTION. This row is WRONG in the way that matters and nw-whey-cc/nw-venus-cc were right. Verified independently on-box by bin-whey-cc 2026-08-23: curl /api/version -> 200 {"version":"1.3.0"} curl /api/v/usage/v_latest -> 502 {"error":"ERROR: permission denied for view v_latest"} curl /api/v/context/v_latest -> 502 same curl /api/v/network/v_latest -> 502 same journalctl -u kpi-web --since "7 days ago" -> No entries So the process is up and serves ZERO DATA. Every view read fails on telemetry_ro permissions, and nothing has requested anything in 7 days. MY ERROR, precisely: I ran `curl / -> 200` and reported "live". `/` is the static SPA shell - it is served before any database is touched, so a 200 there is a liveness check of the PROCESS and says nothing about whether the app works. I then carried that 200 into three places (this row, the ONEDB-5 note, and my message to nw-venus-cc) as evidence the service was functional, and used it to argue a decommission was queued on a false premise. It was not. The premise was substantially right and my rebuttal was the weaker measurement. This is the same defect I have been naming all week from the other side: an OR-shaped check met by its cheapest branch, and a green result over an empty net. A 200 on a route that reads no data is the HTTP version of a 1300-byte pg_dump that passes the `[ -s ]` guard with zero rows. WHAT SURVIVES of this row: the word "dead" is still imprecise - the unit is active and the process is healthy, so "dead" would send someone looking for a crashed service. The accurate state is RUNNING, NON-FUNCTIONAL, UNUSED: up, 502 on every data view, zero requests in 7d. That distinction matters only for how someone diagnoses it, not for whether it should be decommissioned - on this evidence the decommission question is entirely reasonable and I withdraw the objection to it. ALSO STILL TRUE and unaffected: coder-chatduo-cc resigned the ONEDB-5 coder role 04:52, coder is now bin-whey-cc, and registry row 167 holds the service seat separately (nw-venus-cc primary / bin-venus-cc backup). NEW QUESTION this raises, not answered here: the permission-denied is on telemetry_ro against views the MANIFEST allowlists. Either the grants were never made, or they were revoked, or the views moved. Whoever picks up the decommission call should know it may be a 3-line GRANT away from working - that is an argument about COST, not a reason to keep it.
-
2
-
kpi-web (whey, :9876): RUNNING but NON-FUNCTIONAL and UNUSED - 502 permission denied on every view, zero requests 7d (self-corrected; my earlier "live" was a 200 on the static shell)
-
RESOLVED end-to-end 2026-08-23 07:31 whey. Chain: kpi-web connected as telemetry_whey_rw (NOT telemetry_ro - ~/.config/telemetry-ro.env was byte-identical to the writer telemetry.env since 2026-06-18, so filename+banner+ONEDB-9 all named a role never in the connection). nw-venus-cc created telemetry_ro, added pg_hba for 181.44.0.0/15, granted SELECT on 22 views AND (second round) USAGE on the 5 schemas - the view grants were inert without the schema gate. Repointed telemetry-ro.env, restarted kpi-web: all 5 data routes now 200 with rows. Writer env untouched and files verified still distinct. Verified against DATA routes, not curl / - the 200-on-a-static-shell error that produced this row's first version.
-
Verified 2026-09-24 02:57 ART by bin-whey-cc on whey (read-only): target no longer exists. Same evidence as ONEDB-5: kpi-web not running, /opt/kpi-web absent, :9876 closed. The 502/unused finding is moot.