Files
wiki/memory/2026-06-15.md
2026-06-15 10:50:01 +03:00

71 lines
9.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
(see attached image)
## 2026-06-15 — ORCH / watchdog / deploy notes
- ORCH-109 («timeout budgets + launch-time model telemetry») доведена до `done`, PR #129 merged. Реально проверено:
- agent timeouts in prod: developer=3600s, reviewer=3000s, default/others=1800s.
- отдельный merge-gate re-test timeout остаётся 600s (10 минут) — это НЕ часть ORCH-109, заведено отдельно.
- ORCH-109 сначала залипла в `development` после `CI pending after 120s`: developer job done, CI стал green позже, но stage не был повторно продвинут.
- Пнула штатно через `advance_if_gate_passed`: задача пошла в review/testing/deploy и после чистки старых pytest-хвостов смержилась.
- Watchdog:
- `orchestrator-watchdog` был не запущен; после старта сразу увидел `stage_stuck ORCH-109`.
- heartbeat-watchdog Стрим фактически не работал: `/tmp/orch_watch.py` в контейнере отсутствовал, `memory/heartbeat-state.json` был старый.
- Watchdog следит за стадиями/контейнерами/health, но не видел старые отдельные pytest-процессы.
- Старые зависшие процессы:
- Найдены и прибиты 5 старых `python3 -m pytest tests/test_install_lite_script.py ...`, жившие >2 суток и грузившие CPU.
- Это были хвосты ORCH-104 (Lite installer), не ORCH-109.
- Они мешали merge-gate local re-test и привели к timeout despite green CI.
- Plane bugs created:
- ORCH-110 — `BUG: merge-gate local re-test timeout causes false rollback after green CI` (Backlog, high). Без описания решения, только факты/симптомы.
- ORCH-111 — `BUG: watchdog must alert on long-lived pytest/child processes that block the pipeline` (Backlog, high). По просьбе Славы: мониторинг таких процессов обязателен, иначе автономности нет.
- ORCH-112 — `BUG: failed/cancelled task artifacts must be cleaned from shared checkout` (Backlog, urgent). Про cleanup/rollback мусора после failed/cancelled задач.
- ORCH-111:
- Аналитик эскалировал багу в полный цикл: `track=full`, не fast-track.
- ORCH-111 проходила full pipeline, но self-deploy упал на dirty checkout.
- После очистки checkout и prod deploy задача была пнута заново; последний известный статус: стадия `Testing`, reviewer прошёл, tester run_id=682 / job=1913 активен.
- Dirty checkout incident:
- Прод-деплой ORCH-111 упал на `git pull origin main` из-за локальных незакоммиченных изменений в `/home/slin/repos/orchestrator/src/config.py`.
- Грязь относилась к ORCH-104/Lite installer: `src/config.py`, `docs/deployment/LITE_SETUP.md`, `scripts/install_lite.py`, `tests/test_install_lite.py`, `docs/deployment/lite-install.example.yaml`.
- Причина: старый запуск орка оставил файлы в общем checkout main, нарушив изоляцию. Сохранён backup `/home/slin/orchestrator-dirty-backup-20260615-082102`, checkout очищен до `origin/main`, prod deploy затем прошёл успешно.
- Self-deploy notes:
- Deploy hook по умолчанию деплоит staging; для prod нужно явно задавать `TARGET_SERVICE=orchestrator`, `TARGET_PORT=8500`, `PREV_IMAGE_FILE=.deploy-prev-image-prod`.
- После prod deploy `/health → ok`, контейнер `orchestrator` жив на свежем main.
- Tokenator / Opus 4-8:
- `claude-opus-4-8` есть в Tokenator `/models`, правильный id именно `claude-opus-4-8`.
- Прямой completion падает HTTP 402 `Insufficient balance` / balance_rub=0.
- `gpt-5.5` через тот же ключ отвечает, значит API/key живы; проблема именно баланс для Opus.
- Plane availability:
- Plane сам был жив: сайт и API отвечали 200, контейнеры Up.
- Если у одного провайдера не открывается, а у другого открывается — вероятная причина DNS/маршрут/IPv6/фильтрация у провайдера, не Plane.
## 2026-06-15 — ORCH-111 / reaper гонка / ORCH-113
- Разобран инцидент повторной обработки `deploy-staging` у ORCH-111:
- `deployer` успешно завершил агентскую часть (`exit_code=0`, staging log SUCCESS), но job ещё оставался `running`, потому что live-monitor/finalizer продолжал тяжёлую послеагентную финализацию: комментарии, stage transition, security-gate, merge-gate, re-test, prod-deploy.
- `job-reaper` через grace ~300s решил, что это «exit0 but finalizer died», и повторно запустил финализацию deploy-staging.
- Из-за этого параллельно пошли повторные security/merge-gate/re-test; повторный local re-test стал красным и откатил задачу `deploy-staging → development`, пока оригинальная финализация уже доводила prod-deploy до SUCCESS.
- Ключевой вывод: 300s grace недостаточен для тяжёлых deploy-staging финализаций; reaper не должен повторно дёргать stage finalization, пока оригинальный monitor/finalizer ещё жив или есть активный lease/heartbeat финализации.
- ORCH-111 в итоге стала `done`:
- prod deploy был уже выполнен успешно; последующий developer run после отката не внёс кодовых изменений/коммита.
- finalizer увидел, что нужные post-deploy/prod артефакты уже успешны, и задача дозавершилась.
- В БД: task ORCH-111 `stage=done`, updated_at `2026-06-15 06:14:26`; был создан/queued post-deploy-monitor job.
- По просьбе Славы заведена новая urgent bug-task:
- **ORCH-113** — `BUG: job-reaper must not re-run deploy-staging finalization while original finalizer is alive`
- Plane/work item id: `ORCH-113`, UUID `b9fcbeef-00cd-47fc-9874-2ace9b70b7e9`, state `Backlog`, priority `urgent`.
- Суть: запретить ситуацию, где reaper считает job потерянной и повторно запускает deploy-staging/merge-gate, пока оригинальная финализация всё ещё выполняется и может успешно довести задачу до prod/done.
## 2026-06-15 — systemic audit ORCH-110/112/113 → ORCH-114
- По просьбе Славы проведён системный разбор класса отказов вокруг ORCH-111:
- **ORCH-110** закрывает только merge-gate re-test infra-timeout: tree-kill pytest, классификация timeout как infra, bounded retry, пропуск no-op re-test. Это снижает шанс ложного rollback, но не даёт ownership на stage transition.
- **ORCH-112** закрывает dirty shared checkout/artifacts после failed/cancelled задач и перед self-deploy. Это предотвращает `git pull origin main` failure, но не чинит конкурирующие finalizer/reaper/reconciler/webhook входы.
- **ORCH-113** закрывает immediate bug: job-reaper не должен повторно запускать живую deploy-staging финализацию. Но формально это только reaper-vs-monitor.
- Найден незакрытый системный gap: нет единого ownership lease/heartbeat на side-effectful `advance_stage` transition. Потенциальные re-entry источники: live monitor, job-reaper, startup `requeue_running_jobs`, reconciler F-1, webhook advance path. Последствия: двойные security/merge/coverage/image-freshness/prod-deploy side effects и противоречивые rollback/done outcomes.
- Создана urgent Plane-задача:
- **ORCH-114** — `BUG: pipeline stage transitions need ownership lease and smart startup recovery`
- UUID `dd57ad23-7902-4d94-8ac4-c2a07b453781`, state Backlog, priority urgent.
- Scope: explicit transition/finalization ownership lease или heartbeat; job-reaper/startup requeue aware of live/stale finalization; CAS/transition epoch для side-effectful transitions; reconciler/webhook skip при active transition lease; observability + regression tests для deploy-staging/deploy-finalizer/restart recovery.
- В Plane добавлены scope comments к ORCH-110/112/113, чтобы разграничить ответственность и не потерять gap.
- Онтология обновлена: `task_orch_114_transition_lease` linked to `proj_orchestrator`.