Files
autotest/polygon-docs/opus-architecture-audit-response.md

4.0 KiB

Архитектурный аудит polygon v0.2.5 — ответ Опуса

Дата: 2026-07-31

Итоговая оценка

Архитектура здоровая и соразмерная задаче. Blueprint-разбиение, data-driven из STANDS YAML, синхронный run без потоков, единый config/loader — правильные решения.

Но есть структурный разрыв: сервис задеплоен как публичный managed-сервис, при этом спроектирован как эксклюзивный однопользовательский in-memory стенд.


Находки

🔴 1. Публичный деплой + общий global state → изоляция тестов ломается в параллельном CI

Две параллельные pytest-сессии делят одно состояние. reset() одной сессии стирает инстансы другой.

Решение: namespace-изоляция по X-Test-Session: <uuid> ИЛИ per-session контейнер в CI.

🔴 2. Основной API без аутентификации на публичном домене

MOCK_AUTH_TOKEN защищает только /_mock/*. POST /instances, /instanceOperations, run — открыты полностью.

Решение: before_request на уровне app (проверка Authorization: Bearer <любой>) или сетевое ограничение.

🟡 3. Синхронный sleep блокирует весь сервер

При --workers 1, time.sleep(DELAY) в run сериализует ВСЕ запросы. При delay=5 сервер заморожен на 5 секунд.

Конфликтует с исходным планом Опуса (решение Q4 — «ленивый dtFinish»). Реализация ушла в синхронный sleep.

🟡 4. _extract_subresource_name — хрупкий выбор имени

Берётся первое непустое строковое значение в op_params. Порядок параметров не гарантирует что имя пойдёт раньше пароля.

Решение: маппить по коду параметра через cfsParams.

🟡 5. Память не ограничена + нет симуляции ошибок

  • Операции и op_params не чистятся никогда → медленная утечка
  • run всегда isSuccessful=True → мок не умеет эмулировать падение
  • Нет cap на число инстансов

Ответы на вопросы

Q1. In-memory vs Redis. Persistence не нужен для CI. Рестарт = чистый стенд, это фича.

Q2. Масштабирование. Безопасно только при эксклюзивном владении. Рекомендация: polygon per-session в CI (снимает находки 1, 2, 3 разом).

Q3. Генерация YAML при старте. Не надо. Оставить offline. Добавить CI-проверку «from_stands.py даёт тот же результат».

Q4. Мониторинг. Prometheus избыточен. Достаточно /_mock/state + структурные логи.

Q5. Готовность к CI. К последовательному CI — готов. Блокеры для параллельного: изоляция сессий (1), auth API (2), симуляция ошибок (5).

Приоритеты

  1. Решить модель владения — per-session контейнер ИЛИ namespace-изоляция
  2. Симуляция ошибок операций — для негативных тестов
  3. Auth-гейт основного API
  4. Маппинг subresource-имён по коду параметра
  5. Косметика версии