Разбери падение приложения и предложи, что проверять.
Стек: [СТЕК: Python 3.11, FastAPI, PostgreSQL, деплой в Docker]
Стектрейс: [СТЕКТРЕЙС: вставьте целиком, вместе с последней строкой исключения]
Логи перед падением: [ЛОГИ: 30–50 строк до момента ошибки]
Код подозрительного места: [КОД: функция или модуль из последнего кадра трейса]
Когда воспроизводится: [УСЛОВИЯ: раз в сутки под нагрузкой, на локальной машине не повторяется]
Что нужно:
1. Цепочка вызовов до падения — простыми словами, по кадрам трейса: что откуда вызвано и на чём оборвалось.
2. Три версии причины, по убыванию вероятности. По каждой: механизм отказа и почему он согласуется с логами и условиями воспроизведения. Если версия объясняет трейс, но противоречит логам — скажи об этом прямо.
3. Для каждой версии — способ проверки: что залогировать, какой запрос выполнить, какую метрику посмотреть. Проверка должна давать однозначный ответ «эта версия верна или нет».
4. Фикс для первой версии: код с пояснением, что именно он меняет в поведении.
5. Что не чинить: места, которые выглядят подозрительно, но к этому падению отношения не имеют.
Не выдавай одну версию за установленную истину. Если данных в трейсе и логах недостаточно для вывода, скажи, чего именно не хватает, — это полезнее уверенного, но неверного диагноза.
Собрать под себя — поля заполнены рабочими значениями, меняйте их и промпт выше обновится сам
Скармливал реальное падение: FastAPI, раз в сутки под нагрузкой, локально не воспроизводится — классика.
Цепочка вызовов восстановлена корректно, включая переход через middleware, который я сам в трейсе пропустил.
Три версии пришли ранжированными: исчерпание пула соединений к базе, гонка при переиспользовании сессии между корутинами, и таймаут внешнего API без обработки. Первая версия оказалась верной, но убедился я в этом не сразу.
Самая полезная часть — способы проверки. Для пула был предложен конкретный запрос к pg_stat_activity и метрика, которую надо снять в момент пика. Проверка заняла десять минут и дала однозначный ответ.
Где промахнулся: предложенный фикс для первой версии увеличивал размер пула — то есть лечил симптом. Настоящая причина была в незакрываемой сессии внутри фонового таска, и на неё указывала вторая версия. То есть ранжирование по вероятности оказалось неточным, хотя нужная догадка в списке была.
Пункт «что не чинить» тоже сработал: отговорил трогать retry-логику, которая действительно к падению отношения не имела.
