fix(dane): bazy zastane na udziale zostają w użyciu po przejściu na rejestr
build / build (push) Successful in 7s
Testy / Testy warstwy logicznej (silnik) (push) Successful in 10m35s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Failing after 4m52s
Testy / Testy warstwy bazodanowej (ochrona baz) (push) Successful in 9m28s
Testy / Build obrazu silnika B (swisseph) (push) Successful in 7s
Testy / Kontrola składni wszystkich warstw (push) Successful in 5s

Bez tego wdrożenie DAN-27 WYŁĄCZYŁOBY WYSZUKIWANIE. Dotąd bazy działały domyślnie
(wyłączało się je jawnie przez DISABLED_BASES). Po przejściu na rejestr plik bez
wpisu w stanie dostaje `ready`, czyli NIE w użyciu — a stan po wdrożeniu jest
pusty. Efekt: żadna baza nie jest aktywna i program nagle niczego nie znajduje.

Ta cicha zmiana zachowania byłaby gorsza od awarii, bo wygląda jak pusta baza,
a nie jak zepsuty deploy — i szukałoby się jej w warstwie danych albo w indeksie.

Teraz brak PLIKU stanu oznacza pierwsze uruchomienie i bazy zastane są przyjmowane
jako aktywne. Pusty słownik przy ISTNIEJĄCYM pliku to co innego: ktoś świadomie
wszystko odstawił, więc nie wskrzeszamy — osobny test tego pilnuje.

Rozróżnienie jest celowe i też pod testem: `ready` dotyczy plików WGRANYCH przez
ekran (te ktoś musi świadomie włączyć), a nie zastanych przy przejściu na rejestr.
Inaczej nowa baza wchodziłaby do wyników sama, bez niczyjej decyzji.

Przyjęcie działa też na udziale tylko do odczytu: zapis stanu wtedy nie przechodzi,
więc powtórzy się przy każdym uruchomieniu — zachowanie to samo, koszt żaden.

Dwa testy opisujące STARE zachowanie zostały poprawione, bo to one były błędne.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit was merged in pull request #69.
This commit is contained in:
2026-08-09 11:59:00 +02:00
committed by gitea
parent e2b50b284f
commit b838cf4723
2 changed files with 84 additions and 6 deletions
+27 -1
View File
@@ -202,6 +202,30 @@ def _scan(root: Path) -> list[Path]:
if p.is_file() and not p.name.startswith((".", "~$"))]
def _adopt_existing(root: Path) -> dict:
"""Pierwsze uruchomienie: bazy zastane na udziale są OD RAZU w użyciu.
Bez tego wdrożenie DAN-27 wyłączyłoby wyszukiwanie. Dotąd bazy działały
domyślnie (wyłączało się je jawnie przez DISABLED_BASES); po przejściu na
rejestr plik bez wpisu dostaje `ready`, czyli NIE w użyciu — więc pusty stan
po wdrożeniu oznaczałby, że program nagle niczego nie znajduje. Ta cicha
zmiana zachowania byłaby gorsza od awarii, bo wygląda jak pusta baza.
Rozróżnienie jest celowe: `ready` dotyczy plików WGRANYCH przez ekran (te
ktoś musi świadomie włączyć), a nie zastanych przy przejściu na rejestr.
Zapis stanu może się nie udać (udział read-only) — wtedy trudno, przy każdym
uruchomieniu przyjmiemy je na nowo. Zachowanie jest to samo, koszt żaden."""
files = {str(p.relative_to(root)): {"status": ACTIVE, "adopted_at": _now()}
for p in _scan(root)}
data = {"files": files, "rules": {**DEFAULT_RULES}}
try:
_write_state(root, data)
except OSError:
pass
return data
def registry(root: Path | str, *, for_admin: bool = False) -> list[dict]:
"""Pliki na udziale wraz ze stanem. `for_admin` odsłania kwarantannę i powody.
@@ -209,7 +233,9 @@ def registry(root: Path | str, *, for_admin: bool = False) -> list[dict]:
dochodziły do przeglądarki i były tylko ukrywane stylem, wystarczyłby podgląd
źródła strony, żeby poznać reguły walidacji."""
root = Path(root)
data = _read_state(root)
# Brak PLIKU stanu = pierwsze uruchomienie. Pusty słownik przy istniejącym
# pliku to co innego: ktoś świadomie wszystko odstawił, więc nie wskrzeszamy.
data = _read_state(root) if state_path(root).exists() else _adopt_existing(root)
out: list[dict] = []
for p in _scan(root):
rel = str(p.relative_to(root))