get_all/get_one глотают ошибку db.execute и возвращают fallback, но сессию им
отдаёт вызывающий: admin-ручки, beat_schedule, и get_setting_value из
cadastre_fetch/nspd_geo. На Postgres упавший execute оставляет транзакцию в
aborted-состоянии — все последующие запросы ЭТОЙ ЖЕ сессии падают с «current
transaction is aborted», то есть падает не тот, кто виноват.
Голый db.rollback() здесь запрещён: он снёс бы незакоммиченную работу
вызывающего. Средство — SAVEPOINT вокруг самого execute, как в уже закрытом
пункте того же кластера (developer_attribution.py:152).
Мок в тесте ВОСПРОИЗВОДИТ семантику Postgres: упавший запрос переводит сессию в
aborted, дальнейшие падают, откат SAVEPOINT восстанавливает. Это не педантизм.
Существующий образец в tests/test_saturation.py устроен иначе — begin_nested там
пустой контекст-менеджер без aborted-состояния, — и проверка на отравление
проходит независимо от наличия защиты. Проверено экспериментом: со СНЯТЫМ
SAVEPOINT в saturation.py все 19 тестов файла зелёные. Тест, который не может
покраснеть при снятии охраняемого, охраны не проверяет.
Поэтому здесь есть ещё и контроль на сам мок (test_mock_actually_poisons_
without_a_savepoint): без него проверки были бы зелёными по построению.
Тесты: 2 красных на origin/main с настоящим текстом ошибки Postgres
(«current transaction is aborted, commands ignored until end of transaction
block»), 2 контроля зелёные с обеих сторон.
pytest tests/services: 3063 passed, 14 skipped, rc=0
