GET /api/v1/photos/{obj}/{file} берёт сессию через Depends(get_db), делает
SELECT — и держит соединение пула всё время синхронного фетча к ДОМ.РФ.
SQLAlchemy открывает транзакцию на первом запросе, поэтому она ещё и висит
idle-in-transaction.
ЗАМЕР 19.08 по domrf_kn_photos:
всего фотографий 165 208
закешировано локально 1 889 (1.1%)
пойдут ленивым путём 163 319 (98.9%)
То есть почти каждый запрос картинки — удержание соединения на время внешнего
похода (_UPSTREAM_TIMEOUT 8 с, connect 4 с). Пул при этом дефолтный:
create_engine в app/core/db.py без pool_size, значит 5 + 10 overflow = 15
соединений на весь бэкенд. Страница отчёта тянет картинки пачкой — пятнадцать
таких запросов занимают пул целиком, и за ними встают ВСЕ остальные ручки.
Правка: db.close() сразу после того, как значения строки разложены по
локальным переменным, — до фетча и до генерации миниатюры. close() не делает
сессию непригодной: следующий db.execute прозрачно берёт новое соединение.
Тест проверяет ФАКТ отпускания (in_transaction() в момент фетча), а не наличие
db.close() в тексте — иначе он фиксировал бы реализацию, а не свойство. Сессия
в тесте настоящая (SQLite), не мок: на моке in_transaction был бы выдумкой.
Наружу тест не ходит — _fetch_upstream подменён, ДОМ.РФ трогать нельзя.
Двусторонний: против main падает ровно проверка отпускания; два контроля —
«закешированная миниатюра всё ещё отдаётся с диска» и «незарегистрированная
фотография всё ещё 404» — зелёные с обеих сторон.
Хунк форматирования — не мой: pre-commit ruff v0.7.4 против 0.15.12 (#2864).
Refs #2464
