Repository navigation
[docs] docs: unbloat troubleshooting/debugging.md - #72536
Conversation
|
✅ Test Quality Sentinel completed test quality analysis. Test Quality SentinelOutcome: The agent completed and reported no action. A no-op output alone does not verify that all required work was completed or that publication was possible. Agent messages are omitted from this comment. The category uses structured run status, not interpretation of agent prose.
|
There was a problem hiding this comment.
🟡 Changes recommended
The condensed guidance omits the stdin permission caveat, preference for inline JSON, and specific log comparisons needed to troubleshoot intermittently missing commands.
2 open issues
What changed in this PR
Condenses gh-aw’s debugging guide, focusing on failure-investigation reports and missing commands inside agent sandboxes. This is a documentation-only change.
Changes:
- Shortens failure-cluster selection, metadata, and statistics explanations.
- Tightens sandbox troubleshooting and consolidates safe-output payload, stdin, and shell-denial guidance.
- Leaves command examples unchanged.
| File | Description |
|---|---|
docs/src/content/docs/troubleshooting/debugging.md |
Condenses failure-analysis and sandbox troubleshooting prose. |
Review effort: Max
| `command not found` for `jq` or `safeoutputs` is different from an unavailable MCP tool. The setup message `Successfully copied ... safe-outputs files` confirms that server scripts were copied to the runner. It does not confirm that the CLI wrapper was mounted or that its interpreter and directory are available on the agent's `PATH`. | ||
|
|
||
| For intermittent failures, compare one successful and one failing run from the same workflow and deployment. Retain both run URLs, the gh-aw and engine versions, the exact `sandbox:` block, and the generated lock-file image, mounts, and `PATH` configuration. Compare setup, MCP startup, CLI mounting, and agent launch logs. Different self-hosted runner images, custom sandbox images, missing mounts, or shell startup files that reset `PATH` are possible causes, not proof of a provisioning race. | ||
| For intermittent failures, compare one successful and one failing run from the same workflow: run URLs, gh-aw and engine versions, the `sandbox:` block, and the lock file's image, mounts, and `PATH`. Different self-hosted runner images, custom sandbox images, missing mounts, or shell startup files that reset `PATH` are possible causes, not proof of a provisioning race. |
| For intermittent failures, compare one successful and one failing run from the same workflow: run URLs, gh-aw and engine versions, the `sandbox:` block, and the lock file's image, mounts, and `PATH`. Different self-hosted runner images, custom sandbox images, missing mounts, or shell startup files that reset `PATH` are possible causes, not proof of a provisioning race. | ||
|
|
||
| Check `command -v safeoutputs` in the **agent's shell** when permitted, not just in a runner setup step. If the CLI is unavailable, use direct safe-output MCP tools only when the engine exposes them. CLI payloads do not require a separate serializer: pass one single-quoted JSON object, encoding newlines as `\n`, double quotes as `\"`, backslashes as `\\`, and apostrophes as `\u0027`. Unicode can remain literal. | ||
| Check `command -v safeoutputs` in the **agent's shell** when permitted, not just in a runner setup step. If the CLI is unavailable, use direct safe-output MCP tools only when the engine exposes them. CLI payloads take one single-quoted JSON object (encode newlines as `\n`, double quotes as `\"`, backslashes as `\\`, apostrophes as `\u0027`), or stdin via `safeoutputs <tool_name> .`: |

Summary
Condensed
docs/src/content/docs/troubleshooting/debugging.md(one file). Reduction is modest, about 250 words (~10%), below the 20% target.All commands, links, and warnings are preserved.