Naprawa: wyszukiwanie i lista baz po wdrożeniu rejestru plików #72

Merged

gitea merged 1 commits from fix/rejestr-kontrakt into master 2026-08-11 13:17:28 +00:00

Conversation 0 Commits 1 Files Changed 3

+133 -2

gitea commented 2026-08-11 09:26:42 +00:00

Owner

Copy Link

Copy Source

Po wdrożeniu DAN-27 przestało działać wyszukiwanie (500 z /search) i ekran Ustawienia (502 z /bases). Ekran „Pliki" działał — co dobrze pokazuje, gdzie leżał problem: nie w rejestrze, tylko w jego styku z kodem, który zastąpił.

Trzy błędy

1. NameError przy każdym wyszukiwaniu. Przepisując _enabled_files pod rejestr usunąłem lokalny from app import bases, a modułowego w tym pliku nigdy nie było.

2. KeyError na /bases. Rejestr oddawał in_use, a endpoint liczy b["enabled"] — tak samo warstwa logiczna i szablon Ustawień. Rejestr wszedł w miejsce starej listy baz, więc musi mówić jej językiem; oddaje teraz oba pola o tej samej wartości.

3. Cache podawany jako baza. _scan filtrował tylko nazwę pliku, więc zawartość .cache wchodziła do rejestru (pliki w środku nie zaczynają się od kropki), a przy pierwszym uruchomieniu była jeszcze przyjmowana jako aktywna. Ten wyszedł dopiero z nowych testów — nie wiedziałem o nim.

Dlaczego testy tego nie złapały

test_files.py sprawdza rejestr w izolacji i był zielony, podczas gdy produkcja leżała. Przy podmianie mechanizmu groźne nie jest to, co nowy moduł robi w środku, tylko czy mówi tym samym językiem, co jego odbiorcy.

Doszedł test_rejestr_integracja.py — pięć testów punktów styku:

• wyszukiwanie przez dostawcę, obie gałęzie (także ta z DISABLED_BASES, w której siedział NameError)
• kontrakt pól listy baz — każdy odbiorca dostaje to, czego szuka
• endpoint /bases przez trasę, nie przez dostawcę
• odstawienie bazy widziane jednocześnie w wyszukiwaniu i w liczniku na Ustawieniach

Weryfikacja

Dane 37, logika 342, prezentacja 299, render 41 — zielone.

Po merge'u przeładuj warstwę danych przez zero replik i sprawdź Sygnifikatory.

🤖 Generated with Claude Code

Po wdrożeniu DAN-27 przestało działać **wyszukiwanie** (500 z `/search`) i **ekran Ustawienia** (502 z `/bases`). Ekran „Pliki" działał — co dobrze pokazuje, gdzie leżał problem: nie w rejestrze, tylko w **jego styku z kodem, który zastąpił**. ## Trzy błędy **1. `NameError` przy każdym wyszukiwaniu.** Przepisując `_enabled_files` pod rejestr usunąłem lokalny `from app import bases`, a modułowego w tym pliku nigdy nie było. **2. `KeyError` na `/bases`.** Rejestr oddawał `in_use`, a endpoint liczy `b["enabled"]` — tak samo warstwa logiczna i szablon Ustawień. Rejestr wszedł w miejsce starej listy baz, więc musi mówić jej językiem; oddaje teraz oba pola o tej samej wartości. **3. Cache podawany jako baza.** `_scan` filtrował tylko nazwę *pliku*, więc zawartość `.cache` wchodziła do rejestru (pliki w środku nie zaczynają się od kropki), a przy pierwszym uruchomieniu była jeszcze przyjmowana jako aktywna. **Ten wyszedł dopiero z nowych testów — nie wiedziałem o nim.** ## Dlaczego testy tego nie złapały `test_files.py` sprawdza rejestr **w izolacji** i był zielony, podczas gdy produkcja leżała. Przy podmianie mechanizmu groźne nie jest to, co nowy moduł robi w środku, tylko **czy mówi tym samym językiem, co jego odbiorcy**. Doszedł `test_rejestr_integracja.py` — pięć testów punktów styku: - wyszukiwanie przez dostawcę, obie gałęzie (także ta z `DISABLED_BASES`, w której siedział `NameError`) - kontrakt pól listy baz — każdy odbiorca dostaje to, czego szuka - endpoint `/bases` **przez trasę**, nie przez dostawcę - odstawienie bazy widziane **jednocześnie** w wyszukiwaniu i w liczniku na Ustawieniach ## Weryfikacja Dane 37, logika 342, prezentacja 299, render 41 — zielone. Po merge'u przeładuj warstwę danych **przez zero replik** i sprawdź Sygnifikatory. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

gitea added 1 commit 2026-08-11 09:26:43 +00:00

fix(dane): trzy błędy styku rejestru plików z resztą warstwy (DAN-27) ... ac8a0e9fc6

Po wdrożeniu DAN-27 przestało działać wyszukiwanie (500 z /search) i ekran
Ustawienia (502 z /bases). Ekran „Pliki" działał, co dobrze pokazuje, gdzie leżał
problem: nie w rejestrze, tylko w JEGO STYKU z kodem, który zastąpił.

1. NameError przy KAŻDYM wyszukiwaniu. Przepisując `_enabled_files` pod rejestr
   usunąłem lokalny `from app import bases`, a modułowego w tym pliku nigdy nie
   było. Wołanie bases.disabled_entries() wywracało się natychmiast.

2. KeyError na /bases. Rejestr oddawał `in_use`, a endpoint liczy `b["enabled"]` —
   tak samo warstwa logiczna i szablon Ustawień (DAN-15/PRE-09). Rejestr wszedł
   w miejsce starej listy baz, więc musi mówić jej językiem; oddaje teraz oba
   pola o tej samej wartości.

3. Cache podawany jako baza. `_scan` filtrował tylko nazwę PLIKU, więc zawartość
   `.cache` wchodziła do rejestru (pliki w środku nie zaczynają się od kropki),
   a przy pierwszym uruchomieniu była jeszcze przyjmowana jako aktywna. Teraz
   pomijamy wszystko, co leży w ukrytym KATALOGU. Ten wyszedł dopiero z nowych
   testów — nie wiedziałem o nim.

DLACZEGO TESTY TEGO NIE ZŁAPAŁY. test_files.py sprawdza rejestr w IZOLACJI i był
zielony, podczas gdy produkcja leżała. Groźne w takiej podmianie nie jest to, co
nowy moduł robi w środku, tylko czy mówi tym samym językiem, co jego odbiorcy.
Doszedł więc test_rejestr_integracja.py: wyszukiwanie przez dostawcę (obie gałęzie,
także ta z DISABLED_BASES), kontrakt pól listy baz, endpoint /bases przez trasę
oraz odstawienie bazy widziane JEDNOCZEŚNIE w wyszukiwaniu i w liczniku.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

gitea merged commit ac8a0e9fc6 into master 2026-08-11 13:17:28 +00:00

gitea deleted branch fix/rejestr-kontrakt 2026-08-11 13:17:28 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

gitea

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gitea/astrololo#72