126 plikow (md, yaml, sh, py) odwolywalo sie do sciezek sprzed migracji.
15 markdown-linkow [..](..) -> policzona sciezka WZGLEDNA wobec pliku
odsylajacego (wczesniej czesc z nich byla repo-root-relative i nie
rozwiazywala sie z katalogu, w ktorym lezala)
200 odwolan tekstowych (backticki, proza, yaml, importy w kodzie)
-> nowa sciezka repo-root-relative, zgodnie z konwencja repo
5 linkow rodzenstwa (gole nazwy plikow, np. "](DEPLOY.md)") — dzialaly
tylko w starym katalogu; przeliczone recznie
Objete m.in.: CLAUDE.md (scripts/onboard/README.md -> kb/runbooks/
node-onboarding-tool.md, docs/backlog.md -> kb/phases/backlog.md),
README.md, .claude/skills/, 20 session logow, kod jobow.
Ostatnie 5 odwolan pochodzi z tresci wciagnietej rebasem z origin/master
(session log 2026-07-31, override node-agenta na SOLARII, dwie pozycje
backlogu) — wskazywaly na docs/incidents/, docs/kb/modules/ i
services/narty27/README.md sprzed migracji.
Dodany wzajemny link miedzy kb/services/control-plane.md (stub kodu)
a kb/subsystems/control-plane.md (opis, deprecated) — dwa dokumenty o tym
samym systemie, latwe do pomylenia.
Weryfikacja na 790 plikach: 0 odwolan do starych sciezek,
0 martwych linkow markdown. Lint OKF: 190/190 plikow ZGODNE.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2.8 KiB
2.8 KiB
| okf | type | visibility | status | updated | links | |
|---|---|---|---|---|---|---|
| 0.1 | incident | private | active | 2026-08-03 |
|
Fix: paperless-worker@SOLARIA — dwa bugi configu, naprawione i zweryfikowane na żywo (2026-07-12)
Kontekst. Moduł 3 (services/paperless-worker/, split-host OCR worker) był
zdeployowany i brał zadania z kolejki, ale miał dwa bugi w compose:
command: celery ...nie odpalał celery. Obraz paperless-ngx (/sbin/docker-entrypoint.sh) routuje każdy argument NIE zaczynający się od/domanage.py— więccelerylądował jako nieznana subkomenda Django, nie jako program. Fix:command: /usr/sbin/gosu paperless /usr/local/bin/celery ...(ścieżka absolutna wchodzi w gałąźexec "$@"entrypointu;gosu paperlessz przodu bo ta gałąź nie dostaje automatycznego gosu, inaczej proces poszedłby jako root i zepsuł właściciela plików na NFS).- Brak współdzielonego
SCRATCH_DIR. Paperless@PIHA staguje wgrywany plik w/tmp/paperless(domyślnySCRATCH_DIR) i niesie tę ścieżkę w payloadzie zadania celery jako ścieżkę absolutną. Worker@SOLARIA miał własny, lokalny/tmp/paperless— gdy odbierał zadanie zamiast workera PIHA, padałCannot consume ...: File not found. Fix: NFS volumepaperless_scratch(ten sam wzorzec codata/media/consume) na/opt/homelab/data/paperless/scratch(już istniał na PIHA,chown 1000:1000), mount na/tmp/paperlesspo obu stronach.
Oba fixy + uzasadnienie: services/paperless/docker-compose.yml,
services/paperless-worker/docker-compose.yml, kb/services/paperless-worker.md.
Zweryfikowane end-to-end na żywo (branch task/paperless-worker-fix, jeszcze
niezmergowany do master w momencie pisania tego wpisu): 3 dokumenty testowe
wrzucone do consume/ na PIHA, jeden odebrany i dokończony przez worker@SOLARIA
(log: ocrmypdf/tesseract → ConsumeTaskPlugin completed with: Success),
zero File not found. Dokumenty testowe usunięte po teście (document.delete()
- ręczny cleanup plików) — produkcyjne 6 dokumentów nietknięte.
Otwarte (świadomie odłożone, nie blokuje działania):
hosts/solaria/services.yamliinventory/topology.yamlnie mają wpisupaperless-worker(SOLARIA ma tam tylkonode-agent) — było zaplanowane w cutover checkliście README jako krok "przy deployu", ale nigdy nie zrobione. Bez tego wpisu supervisor/observer nie widzą tego serwisu w desired-state — drift (np. worker padnie i nie wstanie) nie zostanie automatycznie wykryty przez agent system, tylko przez brak przetwarzania kolejki.- Test formalnego fallbacku (stop worker@SOLARIA → kolejka mieli na PIHA → start → drenaż) nie był wykonany w tej sesji — mechanizm nie zmienił się tym fixem (był już OK), ale warto zweryfikować przy okazji.