Вариант 3 — это «золотая середина» между ручным управлением и сложными системами очередей типа Celery. Вот как это работает на уровне архитектуры и как это будет выглядеть для тебя.

1. Как это устроено технически

FastAPI предоставляет встроенный механизм BackgroundTasks. Работает это так:

  1. Админ нажимает кнопку «Запустить фоновую синхронизацию».
  2. Браузер отправляет запрос на сервер.
  3. Сервер говорит: «Ок, задачу принял, погнали!» и мгновенно возвращает ответ HTTP 202 Accepted.
  4. Важно: HTTP-соединение разрывается, браузер свободен, но процесс на сервере продолжает жить и выполнять код синхронизации в фоне.

2. Что нужно доработать в коде

Чтобы это было удобно и надежно, нам понадобятся три вещи:

А. Сервисная функция «Вечного цикла»

Мы создаем функцию, которая в цикле вызывает наш существующий sync_missing_moves_batch до тех пор, пока:

  • Либо не закончатся игры без ходов.
  • Либо не будет достигнут лимит (например, 10 000).
  • Либо не произойдет критическая ошибка.

Б. Отслеживание статуса (State)

Поскольку процесс идет в фоне, нам нужно знать: «Он еще работает? Сколько уже скачано? Были ли ошибки?». Самый простой способ для нашего проекта — хранить это в памяти сервера (в синглтоне) или в маленькой таблице в БД.

  • Пример статуса: { "status": "running", "processed": 450, "total": 10000, "errors": 2 }

В. Эндпоинт для проверки (Polling)

Фронтенд будет раз в пару секунд «стучаться» на сервер по адресу /api/admin/sync/status, забирать этот JSON и красиво рисовать полоску прогресса.

3. Плюсы этого подхода

  • Удобство: Вы нажали кнопку, увидели, что процесс пошел, и можете закрыть ноутбук или уйти на другую страницу.
  • Безопасность для UI: Никаких зависших вкладок и «белых экранов» из-за долгих ожиданий.
  • Контроль: Мы можем добавить кнопку «Остановить синхронизацию», которая просто поменяет флаг в памяти сервера, и цикл завершится на следующей итерации.

4. Риски (и как их лечить)

  1. Перезагрузка сервера: Если вы обновите код (сделаете деплой), пока идет синхронизация, фоновая задача умрет.
    • Решение: При запуске сервера проверять, есть ли еще игры без ходов, и (опционально) предлагать продолжить.
  2. Утечки сессий БД: В фоновых задачах нужно очень аккуратно работать с db_session, чтобы не оставить открытых соединений.
  3. Блокировка Dice Chess: Если мы запустим «вечный» цикл без пауз, нас забанят.
    • Решение: Мы оставим тот же delay_ms между играми.

Итоговый сценарий использования:

  1. Ты заходишь в админку.
  2. Видишь: «Пропущено ходов: 10 240».
  3. Вводишь лимит «10 000» и жмешь «Run in Background».
  4. Появляется плашка: «Синхронизация запущена. Обработано: 124/10000…».
  5. Ты можешь закрыть админку. Если зайдешь через 10 минут — она подхватит статус и покажет актуальный прогресс.

Как тебе такая схема? Если нравится, я могу набросать Implementation Plan, как мы внедрим этот механизм в бэкенд и фронтенд.