fix(pipeline-status): align TS wrapper timeout with CI polling budget #69
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/pipeline-status-timeout-alignment"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Что сделано
.opencode/tools/pipeline-status.ts:15:timeout: 60000→timeout: 480000(480s) — TS-обёрткаspawnSyncтеперь даёт Python-оракулу полный CI polling budget вместо того, чтобы убивать его на 60-й секунде..opencode/scripts/pipeline-status.py:61:CI_WAIT_TIMEOUT = 300→CI_WAIT_TIMEOUT = 420(7 мин) — budget CI poll loop увеличен с 5 до 7 минут, чтобы покрывать длинные CI-прогоны.tests/test_pipeline_status_tool.py:133: asserttimeout == 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 уже существовал и тестирован, но не был задокументирован.Почему
TS-обёртка
pipeline-status.tsставилаspawnSync({ timeout: 60000 })(60s), но Python-оракулpipeline-status.pyопрашивает CI доCI_WAIT_TIMEOUT=300секунд. Любой CI-прогон дольше 60s приводил к тому, чтоspawnSyncубивал процесс по SIGTERM — оракул не дорабатывал poll loop и возвращал ошибку вместо финального статуса CI. Это ломало пайплайн на CI-фазе для реальных прогонов.Правка выравнивает таймауты: 480000ms (TS) > 420s (Python) + overhead, так что оракул гарантированно дорабатывает весь poll budget.
CI_POLL_INTERVAL = 10намеренно не меняется.Watch out
60000литерал остаётся вspec-status.ts,project-status.tsиcreate-pr.ts— у них другая семантика (локальные быстрые операции, не CI-поллинг). Слепой find-and-replace60000→480000по репо был бы ошибкой — правка точечная.OPENCODE_CI_WAIT_TIMEOUT/OPENCODE_CI_POLL_INTERVAL, они переопределяют константы в коде — поведение Python не меняется, меняется только дефолт.Pending
repos/slaid098/opencode-config.mdпосле merge (фаза MEMORY пайплайна).spec-status.ts/project-status.tsотдельным issue, если их 60s таймаут окажется недостаточным для их use-case (вне scope этого PR).Closes #68
Code Review Summary
PR точечно выравнивает таймауты TS-обёртки и Python-оракула:
spawnSynctimeout 60s→480s (480000ms) иCI_WAIT_TIMEOUT300→420. Корневая причина (SIGTERM-убийство оракула на 60-й секунде при CI-прогоне >60s) устранена корректно. Дифф минимален (4 файла, +18/−9), тест-регресс обновлён, env-override задокументирован.Positives
spec-status.ts,project-status.ts,create-pr.tsне тронуты (их60000имеет другую семантику — локальные быстрые операции, не CI-поллинг). Find-and-replace был бы ошибкой — автор правильно этого избежал.CI_POLL_INTERVAL = 10намеренно сохранён.test_execute_passes_timeout_to_spawnsyncassert480000+ переписанный docstring исправляет семантическую ошибку (прежде описывал Forgejo HTTP timeout, а не CI-поллинг)..env.exampleописывает обе переменные с пояснением инвариантаTS timeout >= wait_timeout + overhead.## Что сделано/## Почему/## Watch out/## Pendingзаполнены осмысленно,Watch outявно документирует риск ложного find-and-replace и env-override.Suggestions (info, not blocking)
pipeline-status.ts:6 [stale-doc] Tool
descriptionвсё ещё говорит"Blocks up to 5 min while CI runs"— ноCI_WAIT_TIMEOUTтеперь 420s = 7 мин, не 5. Описание стало неточным после увеличения budget. Fix: заменить"5 min"→"7 min"(или"up to CI_WAIT_TIMEOUT").pipeline-status.ts:18 [stale-literal] Error message
"timed out (60s)"хардкодит старое значение — но timeout теперь 480000ms = 480s. Если timeout действительно сработает (редкий случай), пользователь увидит误导ющее "60s". Fix:"timed out (480s)"или вычислять из константы.tests/test_pipeline_status_tool.py:156,172 [paired-stale]
test_execute_timeout_returns_readable_errordocstring говорит"mentioning the 60s timeout"и assert"60s" in result. Тест проходит (потому что line 18 ещё хардкодит "60s"), но это paired stale state: если line 18 исправят на "480s", этот тест сломается. Fix: при обновлении line 18 синхронно обновить docstring + assert на"480s".Примечание: три замечания выше — cosmetic drift, не блокируют merge. Core fix корректен, функциональное поведение правильное, тесты зелёные. Рекомендуется завести отдельный issue для зачистки stale-строк (или включить в этот PR, если автор хочет).
Verdict: APPROVE