bot-backend 80b38fccaa fix(ptica): соединение БД отпускается до похода за фотографией наружу ... 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		2026-08-19 15:37:39 +05:00
..
v1	fix(ptica): соединение БД отпускается до похода за фотографией наружу	2026-08-19 15:37:39 +05:00
__init__.py	init	2026-04-25 13:45:19 +03:00