<b>Migration с aiogram 2 → 3 чаще ломает не код, а прод-логика бота</b>

<b>Migration с aiogram 2 → 3 чаще ломает не код, а прод-логика бота</b>

В проде обычно падают не «красивые» хендлеры, а всё вокруг них: загрузка state, фильтры, middleware и порядок инициализации. Если в v2 бот «сам как-то жил», то в v3 многие скрытые допущения всплывают сразу.

Что проверять в первую очередь:
— FSM: старые ключи и переходы могут перестать совпадать с новой схемой хранения
— Router: хендлеры, которые раньше были в одном файле, теперь надо собирать явно
— Middleware: контекст и порядок прокидывания данных меняются, и это ломает auth, locale, trace-id
— Callback/Data: парсинг и фильтры лучше перепроверить отдельно, особенно если были сложные фабрики

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

Ещё один риск — фоновые задачи и long polling/webhook обвязка. Если там были свои обёртки, после переноса легко потерять обработку исключений, таймауты и graceful shutdown. Это бьёт по стабильности сильнее, чем синтаксис.

Сначала поднимите отдельный стенд, прогоните критические пользовательские цепочки и только потом переносите прод. Самая дорогая ошибка при миграции — считать, что если бот стартует, значит он уже работает.