fix(pipeline-status): align TS wrapper timeout with CI polling budget #68

New issue

Closed

opened 2026-08-13 18:35:26 +03:00 by slaid098 · 0 comments

slaid098 commented

2026-08-13 18:35:26 +03:00

Owner

Контекст

PR #45 (коммит 5295ba2, 11 авг 2026) добавил хардкод timeout: 60000 (60с) в TS-обёртку pipeline-status.ts:15. Таймаут был рассчитан под один Forgejo API-запрос с ретраями (32с worst-case), но не учёл CI-поллинг. Python-оракул pipeline-status.py имеет собственный цикл поллинга _classify_rollup_with_poll (строки 697-723) с бюджетом CI_WAIT_TIMEOUT=300с (5 мин) и интервалом CI_POLL_INTERVAL=10с, но TS-обёртка убивает Python-процесс на 60-й секунде — поллинг не успевает начаться. В результате агент вынужден вручную поллить CI, что нарушает автономный pipeline.

Задача

Поднять TS-обёртку pipeline-status.ts до 480000мс (8 мин) и Python CI_WAIT_TIMEOUT до 420с (7 мин), чтобы оракул сам поллил CI до 7 минут с интервалом 10с. Запас 60с сверх Python-поллинга — на Forgejo-ретраи и оверхед.

Контракты

.opencode/tools/pipeline-status.ts:15: timeout: 60000 → timeout: 480000
.opencode/scripts/pipeline-status.py:61: CI_WAIT_TIMEOUT = 300 → CI_WAIT_TIMEOUT = 420
CI_POLL_INTERVAL = 10 — НЕ меняем (уже соответствует требованию)
tests/test_pipeline_status_tool.py:133: assert timeout == 60000 → timeout == 480000, переписать docstring (нынешний «headroom over 10s×3=32s» некорректен — он про Forgejo-запрос, а не про CI-поллинг)
.env.example: добавить OPENCODE_CI_WAIT_TIMEOUT=420 и OPENCODE_CI_POLL_INTERVAL=10 (env-override в Python уже существует и тестирован, но не задокументирован)

Инварианты

spec-status.ts:16 и project-status.ts:23 имеют тот же литерал timeout: 60000 — НЕ трогать (им 60с достаточно, они не поллят CI)
CI-поллинг логика (CiPollConfig, _load_ci_config, _classify_rollup_with_poll) живёт ТОЛЬКО в pipeline-status.py — никто другой её не импортирует
Нельзя делать слепой find-and-replace 60000 → 480000 — заденет spec-status.ts и project-status.ts

Граничные случаи

CI green/failed сразу → поллинг не запускается, DONE/NOT_DONE возвращается мгновенно (поведение не меняется)
CI IN_PROGRESS > 7 мин → оракул возвращает AMBIGUOUS (не NOT_DONE) — pipeline ставится на паузу (поведение не меняется, просто бюджет больше)
Forgejo API недоступен → ретраи (3×10с + 1с интервал = 32с) внутри поллинга, не должно превышать TS-бюджет 480с

Влияние на связанные компоненты

spec-status.ts, project-status.ts — НЕ затрагиваются (другая семантика, 60с достаточно)
test_pipeline_status_ci.py — проверяет CI_WAIT_TIMEOUT через ps.CI_WAIT_TIMEOUT (L616/L642), может потребовать обновления assert если хардкодит 300
opencode.json — НЕ затрагивается (там только MCP server timeouts 300000, не tool spawnSync)
create-pr.ts — НЕ затрагивается (там RUFF_TIMEOUT_MS=60000 для sub-command, другая семантика)

Вне scope

Добавление regression-guard тестов для spec-status.ts и project-status.ts timeout (test coverage gap, отдельная задача)
Изменение CI_POLL_INTERVAL (уже 10с, соответствует требованию)
Рефакторинг таймаутов в других обёртках

Критерии приемки

pipeline-status.ts имеет timeout: 480000
pipeline-status.py имеет CI_WAIT_TIMEOUT = 420
test_pipeline_status_tool.py asserts timeout == 480000, docstring обновлён
.env.example документирует OPENCODE_CI_WAIT_TIMEOUT=420 и OPENCODE_CI_POLL_INTERVAL=10
spec-status.ts и project-status.ts НЕ изменены
Все тесты проходят

## Контекст PR #45 (коммит `5295ba2`, 11 авг 2026) добавил хардкод `timeout: 60000` (60с) в TS-обёртку `pipeline-status.ts:15`. Таймаут был рассчитан под один Forgejo API-запрос с ретраями (32с worst-case), но не учёл CI-поллинг. Python-оракул `pipeline-status.py` имеет собственный цикл поллинга `_classify_rollup_with_poll` (строки 697-723) с бюджетом `CI_WAIT_TIMEOUT=300с` (5 мин) и интервалом `CI_POLL_INTERVAL=10с`, но TS-обёртка убивает Python-процесс на 60-й секунде — поллинг не успевает начаться. В результате агент вынужден вручную поллить CI, что нарушает автономный pipeline. ## Задача Поднять TS-обёртку `pipeline-status.ts` до 480000мс (8 мин) и Python `CI_WAIT_TIMEOUT` до 420с (7 мин), чтобы оракул сам поллил CI до 7 минут с интервалом 10с. Запас 60с сверх Python-поллинга — на Forgejo-ретраи и оверхед. ## Контракты - `.opencode/tools/pipeline-status.ts:15`: `timeout: 60000` → `timeout: 480000` - `.opencode/scripts/pipeline-status.py:61`: `CI_WAIT_TIMEOUT = 300` → `CI_WAIT_TIMEOUT = 420` - `CI_POLL_INTERVAL = 10` — НЕ меняем (уже соответствует требованию) - `tests/test_pipeline_status_tool.py:133`: assert `timeout == 60000` → `timeout == 480000`, переписать docstring (нынешний «headroom over 10s×3=32s» некорректен — он про Forgejo-запрос, а не про CI-поллинг) - `.env.example`: добавить `OPENCODE_CI_WAIT_TIMEOUT=420` и `OPENCODE_CI_POLL_INTERVAL=10` (env-override в Python уже существует и тестирован, но не задокументирован) ## Инварианты - `spec-status.ts:16` и `project-status.ts:23` имеют тот же литерал `timeout: 60000` — НЕ трогать (им 60с достаточно, они не поллят CI) - CI-поллинг логика (`CiPollConfig`, `_load_ci_config`, `_classify_rollup_with_poll`) живёт ТОЛЬКО в `pipeline-status.py` — никто другой её не импортирует - Нельзя делать слепой find-and-replace `60000` → `480000` — заденет `spec-status.ts` и `project-status.ts` ## Граничные случаи - CI green/failed сразу → поллинг не запускается, DONE/NOT_DONE возвращается мгновенно (поведение не меняется) - CI IN_PROGRESS > 7 мин → оракул возвращает AMBIGUOUS (не NOT_DONE) — pipeline ставится на паузу (поведение не меняется, просто бюджет больше) - Forgejo API недоступен → ретраи (3×10с + 1с интервал = 32с) внутри поллинга, не должно превышать TS-бюджет 480с ## Влияние на связанные компоненты - `spec-status.ts`, `project-status.ts` — НЕ затрагиваются (другая семантика, 60с достаточно) - `test_pipeline_status_ci.py` — проверяет `CI_WAIT_TIMEOUT` через `ps.CI_WAIT_TIMEOUT` (L616/L642), может потребовать обновления assert если хардкодит `300` - `opencode.json` — НЕ затрагивается (там только MCP server timeouts 300000, не tool spawnSync) - `create-pr.ts` — НЕ затрагивается (там `RUFF_TIMEOUT_MS=60000` для sub-command, другая семантика) ## Вне scope - Добавление regression-guard тестов для `spec-status.ts` и `project-status.ts` timeout (test coverage gap, отдельная задача) - Изменение `CI_POLL_INTERVAL` (уже 10с, соответствует требованию) - Рефакторинг таймаутов в других обёртках ## Критерии приемки - `pipeline-status.ts` имеет `timeout: 480000` - `pipeline-status.py` имеет `CI_WAIT_TIMEOUT = 420` - `test_pipeline_status_tool.py` asserts `timeout == 480000`, docstring обновлён - `.env.example` документирует `OPENCODE_CI_WAIT_TIMEOUT=420` и `OPENCODE_CI_POLL_INTERVAL=10` - `spec-status.ts` и `project-status.ts` НЕ изменены - Все тесты проходят

slaid098 added the

bug

label

2026-08-13 18:35:26 +03:00

slaid098 referenced this issue from a pull request that will close it,

2026-08-13 18:38:58 +03:00

fix(pipeline-status): align TS wrapper timeout with CI polling budget #69

slaid098 closed this issue

2026-08-13 18:42:44 +03:00

slaid098 referenced this issue

2026-08-16 17:43:56 +03:00

fix(pipeline-status): report real 480s timeout and align description #72