doc: аудит Fable 5 + моё мнение (Opus vs Fable)
This commit is contained in:
@@ -0,0 +1,62 @@
|
||||
# Архитектурный аудит polygon v0.2.5 — ответ Claude Fable 5
|
||||
|
||||
Дата: 2026-07-31
|
||||
|
||||
## Итоговая оценка
|
||||
|
||||
Архитектура соразмерна задаче и в целом здоровая. Blueprint'ы, data-driven конфиги, единый config/loader.py, синхронный run — правильный выбор. Код читаемый, докстринги честные, критичные контракты задокументированы.
|
||||
|
||||
Главный структурный риск: сервис задеплоен как публичный shared-эндпоинт, но спроектирован как эксклюзивный однопользовательский стенд.
|
||||
|
||||
---
|
||||
|
||||
## Находки
|
||||
|
||||
### 🔴 1. Основной API полностью открыт на публичном домене
|
||||
MOCK_AUTH_TOKEN защищает только /_mock/*. POST /instances, /instanceOperations, run — без проверки.
|
||||
|
||||
### 🔴 2. sleep(DELAY) блокирует /health → риск рестарта контейнера
|
||||
1 sync-воркер, sleep в run замораживает весь сервер включая /health. Комбинация delay=30 + несколько run → healthcheck не отвечает → Nubes рестартит под → состояние потеряно.
|
||||
|
||||
### 🔴 3. Гарантия «1 воркер» через setdefault — не работает
|
||||
os.environ.setdefault("WEB_CONCURRENCY", "1") выполняется при импорте app, а gunicorn читает WEB_CONCURRENCY при старте мастера — до импорта. Если платформа выставит WEB_CONCURRENCY=4, будет 4 воркера и 4 несвязанных MockState.
|
||||
|
||||
### 🟡 4. 500-ки на невалидном вводе
|
||||
set_param: int(param_id) без try → ValueError → 500.
|
||||
/_mock/delay: float("garbage") → 500. Отрицательные значения принимаются молча.
|
||||
|
||||
### 🟡 5. _extract_subresource_name — хрупкий
|
||||
Берёт первое непустое строковое значение. Порядок = порядок set_param. Если executor отправит пароль раньше имени — subresource назовётся паролем.
|
||||
|
||||
### 🟡 6. Мок слишком «добрый»
|
||||
- validate-cfs всегда 200 (required не проверяются)
|
||||
- modify принимает isModifiable: false
|
||||
- операция на creating-инстансе (modify до завершения create)
|
||||
- svcOperationId не сверяется с serviceId инстанса
|
||||
- isSuccessful всегда True — негативные сценарии нельзя тестировать
|
||||
|
||||
### 🟢 7. Мелочи
|
||||
- operations/op_params не чистятся (кроме reset)
|
||||
- stages: [] всегда пуст
|
||||
- total в пагинации — проверить с реальным API
|
||||
|
||||
---
|
||||
|
||||
## Ответы на вопросы
|
||||
|
||||
**Q1. In-memory vs Redis.** Redis не нужен. Потеря состояния при рестарте — фича.
|
||||
|
||||
**Q2. Параллельные тесты.** (A) polygon per-session (рекомендовано) или (B) namespace-изоляция.
|
||||
|
||||
**Q3. Генерация YAML при старте.** Нет. Оффлайн + drift-check тест.
|
||||
|
||||
**Q4. Мониторинг.** Prometheus избыточен. Достаточно логов + /_mock/state.
|
||||
|
||||
**Q5. Готовность к CI.** К последовательному — готов. Блокеры: auth API (1), cap DELAY (2), симуляция ошибок (6).
|
||||
|
||||
## Приоритеты
|
||||
|
||||
1. Токен на весь API + cap DELAY — дёшево, закрывает оба 🔴
|
||||
2. /_mock/fail-next — открывает негативные тесты
|
||||
3. Runtime-проверка воркеров + фикс int(param_id)
|
||||
4. Модель владения (per-session) — отложить
|
||||
Reference in New Issue
Block a user