Как подготовить ошибку к починке

минимальное воспроизведение вместо вороха подробностей

Что это

Статья 3.5 говорит, как сформулировать запрос на починку. Эта — про то, что собрать до того, как его писать.

Разница существенная: правильно оформленный запрос с плохими уликами не поможет. А хорошие улики — это не «побольше всего», а наоборот: минимальный случай, на котором ошибка ещё воспроизводится.

Как выглядит в коде

Ошибка проявилась в боте: команда /stats иногда падает. Вот что с ней делают до того, как звать ИИ.

Шаг 1. Воспроизвести

Ошибка, которую нельзя повторить, не чинится — её починку нельзя проверить. Если команда падает «иногда», надо найти, при каких данных.

for user_id in [1, 2, 3, 17, 42]:
    try:
        build_stats(user_id)
    except Exception as e:
        print(user_id, "->", type(e).__name__, e)

Три строки перебора часто превращают «иногда падает» в «падает на пользователе 17».

Шаг 2. Урезать

Теперь надо убрать из случая всё, что не влияет. Телеграм, база, хендлеры — если ошибка воспроизводится без них, значит, они ни при чём.

# Минимальный случай: ни бота, ни базы
rows = [{"date": "2026-10-01", "amount": 100},
        {"date": "", "amount": 50}]
print(build_stats_from_rows(rows))     # падает

Урезанный случай ценен вдвойне. Он точнее указывает на причину и даёт готовый тест: именно его потом просят оформить как pytest (статья 3.9).

Шаг 3. Собрать три вещи

И только теперь — запрос по шаблону из статьи 3.5.

Как сказать ИИ

Урезать случай можно и вместе с ИИ, это у него получается хорошо:

Вот функция и данные, на которых она падает. Сократи данные
до минимального примера, на котором ошибка ещё
воспроизводится. Код не чини, нужен только пример.

Когда ошибка плавающая:

Эта функция падает примерно раз из пяти, на одних и тех же
аргументах. Какие могут быть причины непостоянного поведения?
Назови три самые вероятные.

Непостоянство почти всегда означает одно из трёх: внешний источник (сеть, время, случайные числа), общее состояние между вызовами или параллельное выполнение. ИИ назовёт их, но проверять придётся тебе.

Чего не надо отдавать

Весь файл, когда хватит функции. Лишний контекст размывает внимание — и твоё, и ИИ.

Логи за сутки. Нужен кусок вокруг ошибки: несколько строк до и несколько после.

Секреты. Токены, ключи, персональные данные пользователей. Перед отправкой лога проверь, что в нём (статья 4.2).

Свой диагноз вместо фактов. «Кажется, проблема в базе» уводит ИИ в сторону, если догадка неверна. Факты отдельно, догадки отдельно — и помечай, что догадка.

На что смотреть

Ошибка «починена», но не воспроизводилась. Если ты не умел воспроизводить её до правки, ты не сможешь проверить, что она ушла. Сначала воспроизведение, потом починка.

Минимальный случай не сохранён. Урезал, починил, выбросил — и через месяц при похожей ошибке всё заново. Урезанный случай стоит сразу превратить в тест.

Чинится симптом, а не причина. Связка статей 2.12 и 2.13: место падения и причина — разные места.

Правка не проверена на исходном случае. Самое обидное: починили, тесты зелёные, а на том самом пользователе 17 всё ещё падает.

Шпаргалка