Document harness watchdog and retry runtime settings - #52511
Conversation
Co-authored-by: dsyme <7204669+dsyme@users.noreply.github.com>
|
👋 The PR looks well-structured and ready: ✅ Focused scope — adds documentation across reference and troubleshooting sections for harness tuning, environment variables, and frontmatter examples. ✅ Complete coverage — documents watchdog semantics, retry policy, engine-specific controls (Copilot, Claude), and includes concrete workflow examples. ✅ Cross-linked — connects harness settings from environment variables, engines, frontmatter, debugging, and timeout docs for discoverability. ✅ Clear descriptions — the PR body and issue #51290 provide full context and acceptance criteria. This is ready for maintainer review!
|
|
✅ Test Quality Sentinel completed test quality analysis. No test files were added or modified in this PR. Test Quality Sentinel skipped.
|
There was a problem hiding this comment.
Pull request overview
Documents public harness watchdog and retry controls and improves runtime troubleshooting.
Changes:
- Adds shared and engine-specific harness settings.
- Documents watchdog behavior, limits, and examples.
- Links runtime tuning guidance across references and troubleshooting.
Show a summary per file
| File | Description |
|---|---|
docs/src/content/docs/troubleshooting/debugging.md |
Adds watchdog troubleshooting. |
docs/src/content/docs/troubleshooting/common-issues.md |
Adds timeout diagnosis and tuning example. |
docs/src/content/docs/reference/frontmatter.md |
Documents structured watchdog configuration. |
docs/src/content/docs/reference/environment-variables.md |
Adds the harness settings reference. |
docs/src/content/docs/reference/engines.md |
Expands harness policy documentation. |
Review details
💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
Suppressed comments (1)
docs/src/content/docs/reference/engines.md:377
- This new shared
GH_AW_HARNESS_*guidance conflicts with the note at line 337, which still says the entireengine.harnessobject only applies to Copilot. Retry fields are compiled for Copilot, Claude, and Codex, so scope that earlier note specifically toengine.harness.use; otherwise readers may reasonably conclude the settings documented here do nothing on Claude/Codex.
You can also set the underlying `GH_AW_HARNESS_*` env vars directly via `engine.env` when you need expression-level control, including `GH_AW_HARNESS_WATCHDOG_TIMEOUT_MS` for the post-result watchdog. Explicit `engine.env` values take precedence over `engine.harness` sub-key values. See [Harness Settings and Runtime Tuning Variables](/gh-aw/reference/environment-variables/#harness-settings-and-runtime-tuning-variables) for supported env vars, units, clamping behavior, and engine-specific controls such as `GH_AW_CLAUDE_STARTUP_RETRIES`.
- Files reviewed: 5/5 changed files
- Comments generated: 5
- Review effort level: Balanced
| engine: copilot | ||
| ``` | ||
|
|
||
| Harness retry and post-result watchdog settings live under `engine.harness` for built-in Copilot, Claude, and Codex harnesses: |
|
|
||
| ### Silent Long-running Commands After a Result | ||
|
|
||
| If the harness log says `post-result watchdog terminating idle process`, the agent already emitted a terminal safe output and then the child process went quiet. The watchdog is dormant until a terminal safe output such as `noop`, a comment, label, push, or pull request creation is observed; diagnostic outputs such as `missing_tool`, `missing_data`, and `report_incomplete` do not arm it. After arming, stdout or stderr activity resets the clock, so quiet builds, tests, or monorepo scans can be terminated even while they are still doing useful CPU or I/O work. |
|
|
||
| `GH_AW_HARNESS_WATCHDOG_TIMEOUT_MS` configures the post-result stdio inactivity watchdog used by the built-in Copilot and Codex harnesses. It is measured in **milliseconds**. The default is `120000` ms (2 minutes), the minimum is `50` ms, and the maximum is `600000` ms (10 minutes). Unset, non-numeric, zero, and negative values use the default; positive values outside the supported range are clamped. | ||
|
|
||
| The watchdog is dormant until the agent emits a terminal safe output. `noop` and ordinary task outputs such as comments, labels, pushes, and pull request creation are terminal. Diagnostic safe outputs such as `missing_tool`, `missing_data`, and `report_incomplete` are not terminal and do not arm the watchdog by themselves. |
| | `watchdog-timeout` | `120` | Post-result idle watchdog timeout in seconds before terminating a quiet process | | ||
|
|
||
| You can also set the underlying `GH_AW_HARNESS_*` env vars directly via `engine.env` when you need expression-level control, including `GH_AW_HARNESS_WATCHDOG_TIMEOUT_MS` for the post-result watchdog. Explicit `engine.env` values take precedence over `engine.harness` sub-key values. | ||
| The post-result watchdog is dormant until the harness observes a terminal safe output. `noop` and ordinary task outputs such as comments, labels, pushes, and pull request creation are terminal; diagnostics such as `missing_tool`, `missing_data`, and `report_incomplete` are not. Once armed, any stdout or stderr activity resets the inactivity clock. A quiet child process can still be terminated while it is doing useful work, and the harness may treat that termination as successful when a terminal safe output already exists. |
| | Variable | Engine | Default | Units / range | Description | | ||
| | --- | --- | --- | --- | --- | | ||
| | `GH_AW_HARNESS_LONG_RUN_TOKEN_THRESHOLD` | Copilot | `10000` | tokens; minimum `0` | Token threshold used to classify long-running partial executions as `long_run_exit` instead of a generic partial execution. Invalid or negative values use the default. | | ||
| | `GH_AW_CLAUDE_STARTUP_RETRIES` | Claude | `1` | retry attempts; range `0`-`2` | Additional fresh-run retry budget for zero-output Claude startup failures. Invalid values use the default; out-of-range integers are clamped. | |
🔍 PR TriageCategory: docs · Risk: low · Priority score: 28/100 (impact 8, urgency 5, quality 15) Score breakdown:
Good candidate for auto-merge once any final doc review is done.
|
Several harness environment variables affected runtime behavior without a user-facing reference, making post-result watchdog termination and retry tuning hard to diagnose. This adds supported configuration docs and separates public knobs from compiler-managed/internal runtime variables.
Harness settings reference
GH_AW_HARNESS_WATCHDOG_TIMEOUT_MSsemantics, including arming conditions, stdio inactivity reset behavior, and success handling after terminal safe outputs.GH_AW_TIMEOUT_MINUTESas compiler-managed and directed users totimeout-minutes.Engine-specific controls
GH_AW_HARNESS_LONG_RUN_TOKEN_THRESHOLD.GH_AW_CLAUDE_STARTUP_RETRIES.Discoverability and troubleshooting
Example workflow-level watchdog tuning:
Equivalent structured frontmatter form: