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

Merged

slaid098 merged 3 commits from fix/pipeline-status/mcp-timeout into main 2026-08-16 17:50:34 +03:00

Conversation 1 Commits 3 Files changed 2 +5 -5

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

Owner

Copy link

Что сделано

• .opencode/tools/pipeline-status.ts:18: сообщение об ошибке при таймауте spawnSync теперь говорит timed out (480s) вместо устаревшего timed out (60s) — реальный таймаут был поднят до 480s в PR #69 (закрыл #68), но сообщение осталось от эпохи 60s.
• .opencode/tools/pipeline-status.ts:6: description tool'а «Blocks up to 5 min» → «Blocks up to 8 min» — приведён в соответствие с фактическим poll budget (CI_WAIT_TIMEOUT=420s + overhead до 480s kill).
• tests/test_pipeline_status_tool.py: docstring убран упоминание 60s; assert в test_execute_timeout_returns_readable_error теперь требует точный timed out (480s) — регрессионный guard от возврата устаревшего текста.

Почему

Issue #67 (таймаут-контракт MCP-обёртки) частично закрыт PR #69: timeout: 60000 → 480000, CI_WAIT_TIMEOUT = 300 → 420. Но остались две несоответствия, которые нарушают критерии приёмки #67:

1. При таймауте пользователь по-прежнему видел ⚠️ pipeline_status failed (timed out (60s)) — ложное сообщение, спека требует «вместо ⚠️ pipeline_status failed (timed out (60s))».
2. Description обещал «up to 5 min», а реальный budget — 8 минут (480s kill) — критерий приёмки «description соответствует реальному поведению» не выполнялся.

Watch out

• Расхождение спеки: секция «Контракты» #67 говорила «description НЕ меняется», но критерий приёмки требует соответствия description реальному поведению. Выбран критерий приёмки (definition of done) — description изменён под фактический 480s таймаут.
• spec-status.ts, project-status.ts, create-pr.ts по-прежнему используют 60s timeout и timed out (60s) — у них другая семантика (локальные быстрые операции, не CI-поллинг), вне scope #67 (зафиксировано в Watch out PR #69).
• Значения согласованы: TS 480000ms >= Python CI_WAIT_TIMEOUT 420s + buffer (критерий приёмки #67).

Pending

—

Closes #67

Closes #67

## Что сделано - `.opencode/tools/pipeline-status.ts:18`: сообщение об ошибке при таймауте `spawnSync` теперь говорит `timed out (480s)` вместо устаревшего `timed out (60s)` — реальный таймаут был поднят до 480s в PR #69 (закрыл #68), но сообщение осталось от эпохи 60s. - `.opencode/tools/pipeline-status.ts:6`: description tool'а «Blocks up to 5 min» → «Blocks up to 8 min» — приведён в соответствие с фактическим poll budget (CI_WAIT_TIMEOUT=420s + overhead до 480s kill). - `tests/test_pipeline_status_tool.py`: docstring убран упоминание 60s; assert в `test_execute_timeout_returns_readable_error` теперь требует точный `timed out (480s)` — регрессионный guard от возврата устаревшего текста. ## Почему Issue #67 (таймаут-контракт MCP-обёртки) частично закрыт PR #69: `timeout: 60000` → `480000`, `CI_WAIT_TIMEOUT = 300` → `420`. Но остались две несоответствия, которые нарушают критерии приёмки #67: 1. При таймауте пользователь по-прежнему видел `⚠️ pipeline_status failed (timed out (60s))` — ложное сообщение, спека требует «вместо `⚠️ pipeline_status failed (timed out (60s))`». 2. Description обещал «up to 5 min», а реальный budget — 8 минут (480s kill) — критерий приёмки «description соответствует реальному поведению» не выполнялся. ## Watch out - Расхождение спеки: секция «Контракты» #67 говорила «description НЕ меняется», но критерий приёмки требует соответствия description реальному поведению. Выбран критерий приёмки (definition of done) — description изменён под фактический 480s таймаут. - `spec-status.ts`, `project-status.ts`, `create-pr.ts` по-прежнему используют 60s timeout и `timed out (60s)` — у них другая семантика (локальные быстрые операции, не CI-поллинг), вне scope #67 (зафиксировано в Watch out PR #69). - Значения согласованы: TS 480000ms >= Python CI_WAIT_TIMEOUT 420s + buffer (критерий приёмки #67). ## Pending — Closes #67 Closes #67

slaid098 added 3 commits 2026-08-16 17:43:57 +03:00

fix(pipeline-status): report real 480s timeout in error message e65a86cfb1

test(pipeline-status): drop stale 60s timeout wording from docstring 214236dd4b

test(pipeline-status): assert exact 480s timeout in error message fe26c2c3a6

slaid098 commented 2026-08-16 17:50:24 +03:00

Author

Owner

Copy link

Code Review Summary

PR приводит сообщение об ошибке таймаута и description tool'а pipeline-status в соответствие с фактическим поведением (timeout 480000ms, CI_WAIT_TIMEOUT=420s), закрывая оставшиеся критерии приёмки #67. Изменения минимальны (5+/5-), тест-регрессия обновлена на точный timed out (480s) — корректный guard. CI зелёный.

Positives

• Точное соответствие: timed out (480s) = timeout: 480000 (480s), description «Blocks up to 8 min» = 480s kill budget — значения согласованы с .env.example (480000ms vs 420s budget).
• Регрессионный тест test_execute_timeout_returns_readable_error теперь требует точную строку timed out (480s) — защита от возврата устаревшего текста.
• Cross-file проверка: ни один скрипт/оракул не парсит строку timed out (60s) или description tool'а (проверено rg по .opencode/scripts/, tests/, opencode.json) — формат сообщения и description не имеют функциональных readers, ломать нечего. spec-status.ts/project-status.ts (60s) — вне scope #67, корректно зафиксировано в Watch out.

Suggestions (info, not blocking)

• .opencode/skills/run-pipeline/SKILL.md:28 [doc] Строка «pipeline-status сам блокирует до 5 мин» устарела — после #69 + этого PR фактический budget 8 мин (480s kill). Поведенчески не ломает (инструкция «не делать sleep» остаётся верной), но число стоит привести к «до 8 мин» для консистентности с новым description.
• tests/test_pipeline_status_ci.py:7 [doc] Docstring «tests for up to 5 minutes» относится к старому CI_WAIT_TIMEOUT=300; сейчас 420s — можно обновить, не критично.
• PR body [hygiene] Строка «Closes #67» продублирована дважды в конце body — косметика.

Verdict: APPROVE

## Code Review Summary PR приводит сообщение об ошибке таймаута и description tool'а `pipeline-status` в соответствие с фактическим поведением (timeout 480000ms, CI_WAIT_TIMEOUT=420s), закрывая оставшиеся критерии приёмки #67. Изменения минимальны (5+/5-), тест-регрессия обновлена на точный `timed out (480s)` — корректный guard. CI зелёный. ### Positives - Точное соответствие: `timed out (480s)` = `timeout: 480000` (480s), description «Blocks up to 8 min» = 480s kill budget — значения согласованы с `.env.example` (480000ms vs 420s budget). - Регрессионный тест `test_execute_timeout_returns_readable_error` теперь требует точную строку `timed out (480s)` — защита от возврата устаревшего текста. - Cross-file проверка: ни один скрипт/оракул не парсит строку `timed out (60s)` или description tool'а (проверено `rg` по `.opencode/scripts/`, `tests/`, `opencode.json`) — формат сообщения и description не имеют функциональных readers, ломать нечего. `spec-status.ts`/`project-status.ts` (60s) — вне scope #67, корректно зафиксировано в Watch out. ### Suggestions (info, not blocking) - **.opencode/skills/run-pipeline/SKILL.md:28** [doc] Строка «`pipeline-status` сам блокирует до 5 мин» устарела — после #69 + этого PR фактический budget 8 мин (480s kill). Поведенчески не ломает (инструкция «не делать sleep» остаётся верной), но число стоит привести к «до 8 мин» для консистентности с новым description. - **tests/test_pipeline_status_ci.py:7** [doc] Docstring «tests for up to 5 minutes» относится к старому `CI_WAIT_TIMEOUT=300`; сейчас 420s — можно обновить, не критично. - **PR body** [hygiene] Строка «Closes #67» продублирована дважды в конце body — косметика. ### Verdict: APPROVE

slaid098 merged commit b82d3f2a0d into main 2026-08-16 17:50:34 +03:00

slaid098 deleted branch fix/pipeline-status/mcp-timeout 2026-08-16 17:50:34 +03:00

slaid098 referenced this pull request from a commit 2026-08-16 17:50:35 +03:00

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

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

bug

Something is not working

  

chore

  

config

  

enhancement

  

refactor

  

security

No labels

bug

chore

config

enhancement

refactor

security

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

slaid098/opencode-config!72

No description provided.