При LOCAL_PUBLIC=vps dev доступен на forbidden-stars.ru, а fail-fast по
SECRET_KEY/ADMIN_PASSWORD работал только в production: снаружи оставались
общеизвестный ключ JWT (подделка любого токена, включая админский) и пароль
админки. Теперь проверка срабатывает при is_published — у прода и у dev на
домене; на нём же cookie_secure.
Dev-инструменты и Swagger на опубликованном dev остаются (решение владельца):
лаунчеры и лог старта перечисляют, что открыто любому посетителю. В .env.example —
что открывает vps и что у dev и prod должны быть разные SECRET_KEY. #69
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LqSoRj99iwVEH5U5fnZgsd
После запуска dev сайт уходил в вечную загрузку без единой ошибки в логе. Открытая
вкладка держит SSE-поток /api/events, и сервер его сам не закрывает. При любой правке
.py (pull, переключение ветки, мёрж) uvicorn --reload останавливает старый процесс,
а тот в graceful shutdown ждёт закрытия всех соединений. Лимита по умолчанию нет,
поэтому ожидание длится вечно: новый процесс не стартует, слушающий сокет остаётся
у reloader'а, соединения принимаются в backlog и никем не обслуживаются. Запрос
/api/users/me висит, RequireAuth крутит спиннер, в логе только "Reloading...".
Воспроизведено тем же способом, каким запускает run.ps1 (uvicorn в отдельном окне):
при открытом SSE и тронутом .py /api/health не отвечал, хотя TCP-соединение
устанавливалось за 12 мс. Сервер ожил ровно в момент закрытия SSE.
Теперь uvicorn запускается с --timeout-graceful-shutdown: по истечении лимита он
отменяет висящие задачи запросов и доводит перезапуск до конца. В dev лимит 2 с, и
тот же сценарий отвечает 200 примерно через 4 с после правки файла. В entrypoint
лимит 10 с: в контейнере тот же механизм держал остановку до SIGKILL по
stop_grace_period (30 с), и lifespan-shutdown не выполнялся. Команды ручного запуска
в README дополнены тем же флагом.
#47
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XfTsytzT6TojfmprRDKiV6
Накат миграций из #36 обрывал запуск dev на Windows. Alembic пишет свои INFO в
stderr, а Windows PowerShell 5.1 при любом перенаправлении stderr нативного exe
превращает каждую строку в NativeCommandError. В начале скрипта стоит
$ErrorActionPreference = "Stop", поэтому ошибка терминирующая: лаунчер умирал
прямо на миграциях, uvicorn и vite не стартовали.
Комментарий в прежнем коде предупреждал про эту ловушку у "2>&1", но перенаправление
в файл наступает на неё ровно так же — проверено воспроизведением, управление
уходит в catch.
Теперь alembic запускается через Start-Process с редиректом обоих потоков в файлы:
его stderr вообще не проходит через поток ошибок PowerShell, решение принимается по
ExitCode. Оба сценария проверены в тех же условиях (ErrorActionPreference = Stop):
обычное применение — код 0, база новее ветки — распознаётся и запуск продолжается.
#45
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BoiJK9ux8peeyjLb8TYjFf
Ветка задачи может принести миграцию, а run.ps1/run.sh сразу запускали uvicorn:
приложение поднималось на старой схеме и падало 500 на первом обращении к новой
таблице. Так вышло с 0012_match_finish_draft — создание партии отвечало «no such
table: match_finish_drafts». В test/prod такого нет, там схему накатывает
entrypoint.sh контейнера.
Отдельно разобран случай «база новее ветки»: после возврата с ветки задачи alembic
не находит ревизию, которой в этой ветке ещё нет. Останавливать запуск тут не за
что — лишние таблицы старому коду не мешают, поэтому печатаем предупреждение и
идём дальше. Настоящая ошибка миграции по-прежнему останавливает запуск.
stderr alembic в run.ps1 уводится в файл: в Windows PowerShell 5.1 «2>&1» на
нативном exe заворачивает каждую строку в ErrorRecord, а решение принимается по
коду возврата. run.ps1 остался строго ASCII.
#36
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BoiJK9ux8peeyjLb8TYjFf
NotBigGhostandClaude Opus 5