Python-скрипт для продакшена: чек-лист перед запуском по cron

Скрипт, который «просто раз в час дергает API», быстро становится частью продукта. До первого таймаута, дубля в базе или молчаливого падения. Минимальный набор защиты лучше заложить сразу.

— конфиг только через env или отдельный файл, без токенов в коде;
— логируйте не только ошибку, но и входные параметры задачи, id сущности, время ответа;
— добавьте таймауты на HTTP, БД и внешние команды;
— делайте операции идемпотентными: повторный запуск не должен портить данные;
— храните lock-файл или используйте блокировку, если два запуска опасны.

Отдельно проверьте выходы из сценария. sys.exit(1) для аварии, понятные коды возврата, запись последнего успешного шага. Если скрипт обрабатывает пачку, не падайте из-за одной плохой строки: складывайте ее в отдельный список и идите дальше.

Хороший признак: скрипт можно запустить руками на тестовом наборе, остановить посередине и безопасно повторить. Если это не так, перед cron рано. Совет: пишите маленький README рядом со скриптом — команда запуска, переменные, пример dry-run и где смотреть логи.

Starlette ломают не роуты, а мелкие ошибки в middleware и ответах

Если Starlette кажется «слишком тонким», проблема обычно не в фреймворке, а в том, как его используют поверх ASGI. Тут важны три вещи: жизненный цикл приложения, порядок middleware и типы ответов.

• Startup/shutdown лучше держать для инициализации клиентов, пулов и кешей. Не делайте там тяжёлую бизнес-логику: при падении инициализации приложение должно падать сразу, а не «жить полуживым».
• Middleware ставьте от внешнего к внутреннему по смыслу: логирование, трейсинг, авторизация, потом уже доменная обработка. Иначе отладка превращается в угадайку.
• Для JSON и стриминга используйте разные Response-классы. Если всё завернуть в один универсальный ответ, легко потерять заголовки, кеширование или корректную передачу тела.

Есть наблюдение которое стоит проверить: большинство багов в Starlette появляются не в endpoint-функциях, а на границе — где вы читаете request body, прокидываете state и смешиваете sync/async.

Если нужен стабильный сервис, начните с дисциплины вокруг ASGI-границ: отдельный middleware для каждого слоя ответственности, явные Response-типы и минимум магии в startup.