Objaw
Na czubku dev padają dwa testy:
FAILED src/django_bpp/tests/test_auth_server.py::test_szablon_logowania_nie_udaje_awarii
FAILED src/django_bpp/tests/test_auth_server.py::test_szablony_authservera_maja_polskie_znaki
Oba na django.template.exceptions.TemplateDoesNotExist: auth_server/login.html, wywołanym z get_template("auth_server/login.html").render({}).
To nie jest regresja gałęzi funkcjonalnej
Zauważone przy weryfikacji #763, ale odtworzone na czystym dev (git checkout --detach origin/dev, ten sam venv i te same kontenery). Baseline dev: 2 failed, 9391 passed. Ta sama para, ten sam błąd.
Co jest ustalone
- Szablon istnieje w repozytorium:
src/django_bpp/templates/auth_server/login.html.
BASE_DIR w settings/base.py:212 to src/django_bpp, a TEMPLATES[0]["DIRS"] to [BASE_DIR/templates] — czyli katalog z tym szablonem formalnie jest na liście.- Objaw dotyczy rozstrzygania szablonu, nie stanu bazy — nie ma związku z pollutionem kontenera testowego ani z kolejnością testów (odtwarza się przy
-p no:randomly).
- W izolacji (
pytest src/django_bpp/tests/test_auth_server.py) przechodzi 18/18. Padają dopiero w pełnym przebiegu.
To ostatnie jest najciekawsze: coś w pełnym przebiegu zmienia rozstrzyganie szablonów. Podejrzani do sprawdzenia w pierwszej kolejności: django.template.loaders.cached.Loader (opakowuje filesystem + app_directories, settings/base.py ok. 278-296) trzymający zapamiętany negatywny wynik, oraz admin_tools.template_loaders.Loader i dbtemplates.loader.Loader, które stoją PRZED loaderami plikowymi. Możliwe też, że jakiś wcześniejszy test podmienia TEMPLATES przez override_settings w sposób przeciekający na inny proces roboczy.
Skąd się wzięło
Testy i szablon pochodzą z 7a029245e (fix(authserver): strona logowania nie udaje awarii; realna strona 403) oraz e57828c30. Warto sprawdzić, czy przechodziły w pełnym przebiegu w momencie scalania, czy zielone CI wynikało z podziału na shardy — przy dwunastu shardach te testy mogły trafić do procesu, w którym problem się nie ujawnia.
Jak odtworzyć
git checkout --detach origin/dev
uv run pytest -n 4 -m "not playwright" -p no:randomly -q
Uwaga na metodykę: nie używać PYTEST_TESTCONTAINERS_REUSE=1 do potwierdzania takich rzeczy. Współdzielona baza między przebiegami daje fałszywe błędy w testach zależnych od stanu (seed_instytucji, cerif_export, api_v1) i potrafi skierować diagnozę w zupełnie złą stronę.
Objaw
Na czubku
devpadają dwa testy:Oba na
django.template.exceptions.TemplateDoesNotExist: auth_server/login.html, wywołanym zget_template("auth_server/login.html").render({}).To nie jest regresja gałęzi funkcjonalnej
Zauważone przy weryfikacji #763, ale odtworzone na czystym
dev(git checkout --detach origin/dev, ten sam venv i te same kontenery). Baselinedev:2 failed, 9391 passed. Ta sama para, ten sam błąd.Co jest ustalone
src/django_bpp/templates/auth_server/login.html.BASE_DIRwsettings/base.py:212tosrc/django_bpp, aTEMPLATES[0]["DIRS"]to[BASE_DIR/templates]— czyli katalog z tym szablonem formalnie jest na liście.-p no:randomly).pytest src/django_bpp/tests/test_auth_server.py) przechodzi 18/18. Padają dopiero w pełnym przebiegu.To ostatnie jest najciekawsze: coś w pełnym przebiegu zmienia rozstrzyganie szablonów. Podejrzani do sprawdzenia w pierwszej kolejności:
django.template.loaders.cached.Loader(opakowuje filesystem + app_directories,settings/base.pyok. 278-296) trzymający zapamiętany negatywny wynik, orazadmin_tools.template_loaders.Loaderidbtemplates.loader.Loader, które stoją PRZED loaderami plikowymi. Możliwe też, że jakiś wcześniejszy test podmieniaTEMPLATESprzezoverride_settingsw sposób przeciekający na inny proces roboczy.Skąd się wzięło
Testy i szablon pochodzą z
7a029245e(fix(authserver): strona logowania nie udaje awarii; realna strona 403) oraze57828c30. Warto sprawdzić, czy przechodziły w pełnym przebiegu w momencie scalania, czy zielone CI wynikało z podziału na shardy — przy dwunastu shardach te testy mogły trafić do procesu, w którym problem się nie ujawnia.Jak odtworzyć
git checkout --detach origin/dev uv run pytest -n 4 -m "not playwright" -p no:randomly -qUwaga na metodykę: nie używać
PYTEST_TESTCONTAINERS_REUSE=1do potwierdzania takich rzeczy. Współdzielona baza między przebiegami daje fałszywe błędy w testach zależnych od stanu (seed_instytucji,cerif_export,api_v1) i potrafi skierować diagnozę w zupełnie złą stronę.