auto-sync: 2026-06-04 11:10:01
This commit is contained in:
Stream
152
tasks/orchestrator/DEV_TASK_OBSERVABILITY_FIXES.md
Normal file
152
tasks/orchestrator/DEV_TASK_OBSERVABILITY_FIXES.md
Normal file
@@ -0,0 +1,152 @@
|
|||||||
|
# DEV TASK: orchestrator — 4 правки (merge-gate, токены, Plane→Done, артефакты)
|
||||||
|
|
||||||
|
Все правки в репо **orchestrator** на проде: `slin@82.22.50.71:/home/slin/repos/orchestrator`.
|
||||||
|
Прямой push в main запрещён (pre-receive hook) → **только через PR в Gitea**.
|
||||||
|
Gitea токен: `docker exec orchestrator printenv ORCH_GITEA_TOKEN`.
|
||||||
|
Одна ветка `fix/observability-and-merge-gate` от актуального main, **один PR** со всеми 4 правками.
|
||||||
|
Baseline pytest: **227 passed + 10 failed** (10 failed = off-limits: 9 HMAC/401 + 1 webhook-POST — НЕ чинить).
|
||||||
|
После всех правок: passed должно вырасти (новые тесты), те же 10 failed.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ПРАВКА 1 (критичная): вторая дверь баг-8 — gitea merge обходит deploy-QG
|
||||||
|
|
||||||
|
**Файл:** `src/webhooks/gitea.py`
|
||||||
|
|
||||||
|
**Проблема:** ветка `action=="closed" and pr.get("merged", False)` слепо ставит `done`
|
||||||
|
для ЛЮБОЙ стадии. deployer мержит PR в начале работы → webhook merged прилетает за ~30 сек →
|
||||||
|
задача `done` ПОКА deployer ещё работает → его вердикт `deploy_status: FAILED` игнорируется,
|
||||||
|
`check_deploy_status` не вызывается. Фейк-done.
|
||||||
|
|
||||||
|
**Текущий код (≈стр 336-339):**
|
||||||
|
```python
|
||||||
|
elif action == "closed" and pr.get("merged", False):
|
||||||
|
update_task_stage(task_id, "done")
|
||||||
|
notify_stage_change(task_id, current_stage, "done")
|
||||||
|
logger.info(f"Task {task_id}: PR merged, stage → done")
|
||||||
|
```
|
||||||
|
|
||||||
|
**Нужно:** при `current_stage == "deploy"` merge-вебхук НЕ должен ставить done напрямую —
|
||||||
|
done на deploy решает ТОЛЬКО `check_deploy_status` (через `advance_stage` при завершении
|
||||||
|
deployer-job). Для остальных стадий — поведение merge сохранить.
|
||||||
|
```python
|
||||||
|
elif action == "closed" and pr.get("merged", False):
|
||||||
|
# БАГ 8 (вторая дверь): на стадии deploy done гейтится вердиктом deployer'а
|
||||||
|
# (check_deploy_status), а НЕ фактом merge PR — deployer мержит PR в начале
|
||||||
|
# работы, merge != успешный деплой. advance_stage отработает при завершении job.
|
||||||
|
if current_stage == "deploy":
|
||||||
|
logger.info(
|
||||||
|
f"Task {task_id}: PR merged at deploy stage — done gated by deployer "
|
||||||
|
f"verdict (check_deploy_status), ignoring merge-driven done."
|
||||||
|
)
|
||||||
|
return
|
||||||
|
update_task_stage(task_id, "done")
|
||||||
|
notify_stage_change(task_id, current_stage, "done")
|
||||||
|
logger.info(f"Task {task_id}: PR merged, stage → done")
|
||||||
|
```
|
||||||
|
**НЕ дублировать advance_stage из вебхука — только молчаливый return на deploy** (иначе гонка).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ПРАВКА 2 (критичная): учёт токенов — показывать ПОЛНЫЙ вход (cache_read теряется)
|
||||||
|
|
||||||
|
**Файлы:** `src/usage.py` (+ миграция БД для cache_creation, если решишь хранить).
|
||||||
|
|
||||||
|
**Проблема:** Claude CLI `--output-format json` отдаёт `usage.input_tokens` = только
|
||||||
|
НЕкэшированный свежий вход (~20-80 токенов). 99.99% реального входа в
|
||||||
|
`cache_read_input_tokens` (1-8 МЛН) + `cache_creation_input_tokens`. Сейчас:
|
||||||
|
- `parse_usage_from_text` сохраняет `input_tokens` и `cache_read_tokens` отдельно, но
|
||||||
|
**`cache_creation_input_tokens` НЕ парсится/НЕ хранится** → теряется.
|
||||||
|
- `usage_comment` показывает ТОЛЬКО `fmt_tokens(input_tokens)` → "21 in" при реальных 1.1М.
|
||||||
|
- `task_usage_summary` агрегирует `SUM(input_tokens)` → "221 токенов вход" на всю задачу. Абсурд.
|
||||||
|
|
||||||
|
**Что сделать:**
|
||||||
|
1. **Парсинг** (`parse_usage_from_text`, возвращаемый dict): добавить
|
||||||
|
`cache_creation_tokens = _int(usage.get("cache_creation_input_tokens"))`.
|
||||||
|
2. **БД**: добавить колонку `cache_creation_tokens INTEGER` в `agent_runs`
|
||||||
|
(idempotent миграция: `ALTER TABLE ... ADD COLUMN` в try/except, как делаются
|
||||||
|
существующие миграции в проекте — найди где инициализируется схема, например
|
||||||
|
`db.py`/`migrations`; НЕ ломай существующую схему). `record_usage` пишет это поле.
|
||||||
|
3. **Отображение** `usage_comment` — формат:
|
||||||
|
```
|
||||||
|
💻 Developer готов · 8.5M in (8.4M cached) / 45.8k out · $7.29
|
||||||
|
```
|
||||||
|
где `in_total = input_tokens + cache_read_tokens + cache_creation_tokens`,
|
||||||
|
а `cached = cache_read_tokens + cache_creation_tokens`. Если cached==0 — показывать
|
||||||
|
просто `8.5M in / 45.8k out` (без скобки).
|
||||||
|
4. **`task_usage_summary`**: агрегировать `total_in` как
|
||||||
|
`SUM(input_tokens + cache_read_tokens + cache_creation_tokens)`, плюс отдельно
|
||||||
|
`total_cached = SUM(cache_read_tokens + cache_creation_tokens)`.
|
||||||
|
`task_summary_comment` показывает: `📊 Итого по задаче: <total_in> вход (<cached> cached) / <out> выход · <cost>`.
|
||||||
|
5. **Существующие строки** в БД (с NULL в cache_creation) — COALESCE(...,0), не падать.
|
||||||
|
|
||||||
|
**НЕ трогать** расчёт `cost_usd` — он берётся из `total_cost_usd` CLI и корректен.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ПРАВКА 3: статус Plane должен доезжать до `Done`
|
||||||
|
|
||||||
|
**Файлы:** найти где после успешного deploy задача завершается (`stage_engine.advance_stage`
|
||||||
|
deploy→done success-ветка) и где синхронизируется Plane-state (`plane_sync` / `plane_notify_stage`).
|
||||||
|
|
||||||
|
**Проблема:** ET-012 в Plane застрял на `In Progress` (последний переход `Testing → In Progress`),
|
||||||
|
финального Plane-state `Done` нет. Done проставился только в очереди оркестратора (из-за
|
||||||
|
правки 1 раньше merge-вебхук вообще обходил флоу). После правки 1 deploy→done пойдёт через
|
||||||
|
`check_deploy_status` SUCCESS-ветку — на этом переходе нужно синхронизировать Plane-state в `Done`.
|
||||||
|
|
||||||
|
**Что сделать:** в success-ветке deploy→done (когда `check_deploy_status` вернул True)
|
||||||
|
вызвать обновление Plane-state в финальный `Done`/`Completed` (использовать существующий
|
||||||
|
маппинг PLANE_STATES — НЕ менять сам маппинг, только убедиться что финальный переход
|
||||||
|
вызывается). Проверь по `PLANE_STATES`, как называется терминальный стейт, и что
|
||||||
|
`plane_notify_stage(work_item_id, "deploy", "done")` доводит до него.
|
||||||
|
**Ограничение:** НЕ менять PLANE_STATES маппинг и status-only verdict-модель.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ПРАВКА 4: все агенты прикладывают ссылки на артефакты (не только analyst)
|
||||||
|
|
||||||
|
**Файлы:** где формируются per-agent finish-комменты (`usage_comment` в usage.py и/или
|
||||||
|
место вызова в launcher/stage_engine, где постится коммент в Plane после агента).
|
||||||
|
|
||||||
|
**Проблема:** только analyst прикладывает ссылки на доки. Architect/developer/reviewer/
|
||||||
|
tester/deployer постят только токены, без ссылок на свои артефакты.
|
||||||
|
|
||||||
|
**Что сделать:** к финиш-комменту каждого агента добавить ссылку(и) на его артефакт(ы) в Gitea
|
||||||
|
(использовать `gitea_public_url` — он уже есть для кликабельных ссылок, см. PR #14).
|
||||||
|
Маппинг агент → артефакт (путь в репо `docs/work-items/{work_item_id}/`):
|
||||||
|
- **architect** → ADR-файлы `docs/work-items/{wid}/06-adr/*.md` (или design-док стадии architecture)
|
||||||
|
- **developer** → ссылка на PR (номер PR уже известен в флоу) + branch
|
||||||
|
- **reviewer** → `docs/work-items/{wid}/12-review.md`
|
||||||
|
- **tester** → `docs/work-items/{wid}/13-test-report.md`
|
||||||
|
- **deployer** → `docs/work-items/{wid}/14-deploy-log.md`
|
||||||
|
- **analyst** → как сейчас (не ломать).
|
||||||
|
|
||||||
|
Формат ссылки — как у analyst сейчас (markdown-ссылка на файл в Gitea через gitea_public_url:
|
||||||
|
`http://git.../admin/{repo}/src/branch/{branch}/docs/work-items/{wid}/12-review.md`).
|
||||||
|
Если конкретный артефакт-файл для агента отсутствует — ссылку для него пропустить (не падать).
|
||||||
|
**Ограничение:** НЕ менять формат коммента analyst, НЕ трогать gitea_public_url конфиг.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ОГРАНИЧЕНИЯ (общие, НЕ трогать)
|
||||||
|
- HMAC, project-filter (`get_project_by_repo`), nginx, openclaw.json, .env, queue (кроме чтения),
|
||||||
|
PLANE_STATES маппинг, conftest.py, status-only verdict-модель, gitea_public_url конфиг.
|
||||||
|
- Сохранить блок launcher.py:475.
|
||||||
|
- НЕ менять ветки `action=="reviewed"` (APPROVED/REQUEST_CHANGES) в gitea.py.
|
||||||
|
- Стадии кроме deploy в gitea.py merge-обработчике — поведение сохранить.
|
||||||
|
|
||||||
|
## ТЕСТЫ (обязательно)
|
||||||
|
- **Правка 1:** 2 теста (merge на deploy → НЕ done; merge на не-deploy → done).
|
||||||
|
- **Правка 2:** тесты парсинга cache_creation; usage_comment с cached/без; task_usage_summary
|
||||||
|
суммирует все три компонента входа.
|
||||||
|
- **Правка 3:** тест/проверка что success deploy→done доводит Plane до терминала (мок plane_sync).
|
||||||
|
- **Правка 4:** тест что usage_comment/finish-коммент содержит ссылку на артефакт для
|
||||||
|
reviewer/tester/deployer (мок).
|
||||||
|
- Полный `pytest` зелёный (кроме тех же 10 off-limits).
|
||||||
|
|
||||||
|
## СДАЧА
|
||||||
|
- Ветка `fix/observability-and-merge-gate` от актуального main, один PR в Gitea.
|
||||||
|
- НЕ мержить PR сам — оставить на ревью Стрим.
|
||||||
|
- Отчёт: `tasks/orchestrator/reports/dev-2026-06-04-observability-fixes.md` —
|
||||||
|
commit-хеш, номер PR, вывод pytest (passed/failed), краткий diff по каждой из 4 правок.
|
||||||
|
- Сообщить: номер PR + результат pytest + что именно изменилось в каждой правке.
|
||||||
Reference in New Issue
Block a user