Найти причину падения по стектрейсу в Kimi — с планом проверки

Разбери падение приложения и предложи, что проверять.

Стек: [СТЕК: Python 3.11, FastAPI, PostgreSQL, деплой в Docker]
Стектрейс: [СТЕКТРЕЙС: вставьте целиком, вместе с последней строкой исключения]
Логи перед падением: [ЛОГИ: 30–50 строк до момента ошибки]
Код подозрительного места: [КОД: функция или модуль из последнего кадра трейса]
Когда воспроизводится: [УСЛОВИЯ: раз в сутки под нагрузкой, на локальной машине не повторяется]

Что нужно:

1. Цепочка вызовов до падения — простыми словами, по кадрам трейса: что откуда вызвано и на чём оборвалось.

2. Три версии причины, по убыванию вероятности. По каждой: механизм отказа и почему он согласуется с логами и условиями воспроизведения. Если версия объясняет трейс, но противоречит логам — скажи об этом прямо.

3. Для каждой версии — способ проверки: что залогировать, какой запрос выполнить, какую метрику посмотреть. Проверка должна давать однозначный ответ «эта версия верна или нет».

4. Фикс для первой версии: код с пояснением, что именно он меняет в поведении.

5. Что не чинить: места, которые выглядят подозрительно, но к этому падению отношения не имеют.

Не выдавай одну версию за установленную истину. Если данных в трейсе и логах недостаточно для вывода, скажи, чего именно не хватает, — это полезнее уверенного, но неверного диагноза.

Собрать под себя — поля заполнены рабочими значениями, меняйте их и промпт выше обновится сам