Frank
8af40c402b
Landing blocker for #61 and #63: the deployment checkout is 12 commits behind and `merge --ff-only` refuses while tracked paths are dirty. Discard is not available here (workspace policy: no `checkout`/`stash` on shared state), so the dirt is committed. - `agent/APPEND_SYSTEM.md`: the point-of-use / one-work-log / PR-link doctrine, already byte-identical to `origin/main` (`cmp` against the trunk blob: no difference). No new prose — the commit exists so the trunk merge can proceed. - `agent/config.yml` and `agent/managed-skills/**`: the machine-live tier the heartbeat owns (AGENTS.md § Live-sync tiers). `ALLOW_SECRETS=1` was used, deliberately and after auditing the staged diff by hand: the only credential-shaped strings in it are two copies of `AKIA0000000000000EXAMPLE` — the inert all-zero AWS example id — and they appear inside the two skill pages that teach that exact placeholder shape. This checkout is still running the pre-#61 hook; the merged gate (value-scoped placeholder filter, `71601f7`) exempts this value, so the refusal dies with this landing. No `--no-verify` was used: the gate ran and its verdict is recorded here. Refs #61
42 lines
2.4 KiB
Markdown
42 lines
2.4 KiB
Markdown
---
|
|
name: omp-background-job-deadline-debug
|
|
description: "Diagnose a background bash job/service killed mid-run (\"Command timed out after Ns\") in omp: find which deadline owned it (tools.maxTimeout cap vs async default), prove it from the bundle, and launch long jobs uncapped as ready-log services."
|
|
---
|
|
|
|
# Omp background-job deadline forensics
|
|
|
|
Symptom: an async `bats`/build job dies with `[Command timed out after 300s|600s]`
|
|
while the same launch once ran 18+ min ("no deadline").
|
|
|
|
## Cause map (proven against the pinned bundle)
|
|
Resolver in `dist/cli.js`: `let v=n??300, R=v===0, k=R?void 0:ep("bash",v,x)` where
|
|
`qx.bash={default:300,min:1,max:3600}` and `x` = config key `tools.maxTimeout`
|
|
("Maximum timeout in seconds the agent can set for any tool", default 0).
|
|
- Request absent → `qx.bash.default` 300 s.
|
|
- Request > 0 → clamped by `tools.maxTimeout` when set (e.g. 600 caps a 1800 request).
|
|
- Request 0 → meant "no deadline", but `0` sometimes arrives as missing (falsy drop
|
|
upstream of the resolver) → silently 300 s. Filed as tool issue; treat any
|
|
async job over ~5 min as untrustworthy.
|
|
|
|
## Diagnose in three moves
|
|
1. `grep -o 'qx={bash:{[^}]*}' <omp bundle>` — policy table (`command -v omp` →
|
|
`readlink -f` → `dist/cli.js`).
|
|
2. `read cfg://tools` — live `maxTimeout` (value ≠ 0 explains any hard cap).
|
|
3. Compare kill notices: the number in "killed once it has run Ns" is the resolved
|
|
deadline; 300 = default reached (request dropped), other values = your request
|
|
or the config cap.
|
|
|
|
## Launching jobs longer than the cap
|
|
- Named **services are not deadline-capped**: `bash(name:"x", pty:false, command:"…; echo DONE >> log", ready:{log:"DONE", timeout:900})`.
|
|
Readiness fires on the log pattern; result does NOT auto-deliver — `wait` on it or read `proc://x` after the supervisor notice.
|
|
- NEVER end the service command with `echo "EXIT $?" >> log` and trust the
|
|
supervisor's exit code — the trailing echo masks it (supervisor reports 0 while
|
|
the log says EXIT 1). The log line is the truth; grep the log for the recorded
|
|
code and `^not ok` before believing any "exit code 0".
|
|
- Do not raise `tools.maxTimeout` unasked: session-scoped `write cfg://tools/maxTimeout`
|
|
needs user approval and may be declined — respect it, use the service route.
|
|
|
|
## Multi-suite hazard
|
|
Suites that rebuild shared artifacts per test (e.g. dankvoice bats rebuilds `dist/`)
|
|
must not run concurrently — one suite at a time, or per-worktree copies only.
|