9.4 KiB
9.4 KiB
(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.
- Найдены и прибиты 5 старых
- 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-110 —
- 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 затем прошёл успешно.
- Прод-деплой ORCH-111 упал на
- 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.
- Deploy hook по умолчанию деплоит staging; для prod нужно явно задавать
- 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_at2026-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, UUIDb9fcbeef-00cd-47fc-9874-2ace9b70b7e9, stateBacklog, priorityurgent. - Суть: запретить ситуацию, где reaper считает job потерянной и повторно запускает deploy-staging/merge-gate, пока оригинальная финализация всё ещё выполняется и может успешно довести задачу до prod/done.
- ORCH-113 —
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 mainfailure, но не чинит конкурирующие finalizer/reaper/reconciler/webhook входы. - ORCH-113 закрывает immediate bug: job-reaper не должен повторно запускать живую deploy-staging финализацию. Но формально это только reaper-vs-monitor.
- Найден незакрытый системный gap: нет единого ownership lease/heartbeat на side-effectful
advance_stagetransition. Потенциальные re-entry источники: live monitor, job-reaper, startuprequeue_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.
- ORCH-114 —
- В Plane добавлены scope comments к ORCH-110/112/113, чтобы разграничить ответственность и не потерять gap.
- Онтология обновлена:
task_orch_114_transition_leaselinked toproj_orchestrator.