From 52e412dba35faf33ee4043949b86cf7773a26fcf Mon Sep 17 00:00:00 2001 From: oskar Date: Sun, 12 Jul 2026 20:11:34 +0200 Subject: [PATCH] =?UTF-8?q?docs(backlog):=20bug=20checkpoint=20observera?= =?UTF-8?q?=20(leksykalne=20por=C3=B3wnanie=20=C5=9Bcie=C5=BCek=20zatruwa?= =?UTF-8?q?=20w=C4=99ze=C5=82)=20+=20bug=20deploy-local.sh=20rozk=C5=82ada?= =?UTF-8?q?=20control-plane=20na=20ghostach?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/backlog.md | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/docs/backlog.md b/docs/backlog.md index a49b3f2..dfbee03 100644 --- a/docs/backlog.md +++ b/docs/backlog.md @@ -560,3 +560,45 @@ mapy uid/gid. capabilities.yaml (żeby deploy mógł weryfikować/wymuszać spójność). - Agenci NIE powinni montować prywatnego .ssh użytkownika — zawsze dedykowany katalog z własnym kluczem pod właściwym uid (wzorzec z fixa 2026-07-10). + +## Bug: checkpoint observera po ścieżce leksykalnej — kruchy, zatruwa węzeł na zawsze (2026-07-12) + +**Objaw.** PIHA była "martwa" dla observera ~34 dni mimo działającego node-agenta. +Eventy dojeżdżały na VPS (7344 plików w /opt/homelab/events/piha/), ale observer +ich NIE konsumował — `last_seen` nie drgnął, shadow-read logował +`SHADOW_LIVENESS_MISMATCH node=piha event=dead prom=up` z rosnącym wiekiem. + +**Root cause.** `observer_checkpoint.json` trzyma per-węzeł ostatnio przetworzoną +ŚCIEŻKĘ i porównuje ją LEKSYKALNIE (stringowo), awansując tylko "do przodu". +Checkpoint PIHA utknął na `evt-unknown-1781254800-ha_update_available-homeassistant-951.json` +(event z HA, który wpadł do katalogu piha/ z node="unknown"). Nowe eventy nazywają się +`evt-piha--...`, a leksykalnie **"evt-piha-…" < "evt-unknown-…"** (bo `p` < `u`), +więc KAŻDY nowy event był uznawany za starszy niż checkpoint i pomijany. + +**Fix doraźny (zastosowany).** Usunięcie wpisu `piha` z node_checkpoints + restart +observera → 7344 eventy przetworzone, `last_seen_age` spadł z 2 082 036 s (~24 dni) +do 19 s, status=online/fresh, mismatch zniknął. + +**Fix systemowy (DO ZROBIENIA).** Porównanie po ścieżce jest z gruntu kruche — +wystarczy JEDEN plik o "większej" nazwie (inny node w katalogu, inny prefiks) żeby +trwale zablokować węzeł. Checkpoint powinien opierać się na **timestampie** (jest +w nazwie: `evt---`) albo mtime pliku, nie na kolejności alfabetycznej. +Dodatkowo: zbadać, czemu eventy z node="unknown" (HA) trafiają do katalogu innego węzła. + +## Bug: deploy-local.sh control-plane pada na ghost-kontenerach i zostawia mózg rozłożony (2026-07-12) + +**Objaw.** `bash deploy-local.sh` przerwał się w połowie: +`Error response from daemon: No such container: 5ee6fec5455d_control-plane-ui` → +deploy abort → **ZERO kontenerów control-plane** (`docker ps -a` pusty). Mózg całkowicie +down. Zdarzyło się DWA RAZY tego samego dnia. Ratunek: ponowny `deploy-local.sh` +(gdy ghost już zniknął, compose stawia czysto). + +**Root cause (podejrzenie).** Ten sam COMPOSE_PROJECT_NAME divergence / ghost +hash-prefixed containers, co przy `deploy.sh vps` (naprawione guardem 3b71707). +Compose próbuje Recreate kontenera pod nazwą `_control-plane-ui`, której Docker +już nie zna → błąd → `set -e` przerywa deploy w połowie. + +**Fix (DO ZROBIENIA).** deploy-local.sh powinien być odporny: cleanup ghostów przed +recreate (`docker compose down --remove-orphans` albo jawne usunięcie hash-prefixed +kontenerów), ewentualnie jawny `-p` (COMPOSE_PROJECT_NAME) żeby nazwy były deterministyczne. +Deploy mózgu NIE MOŻE zostawiać control-plane w stanie zero-kontenerów.