fix(ward): give aos-test a timeout the suite can actually finish inside #1003

Merged

coilysiren merged 1 commit from aos/claude/aos-test-timeout into main

2026-08-12 08:11:58 +00:00

coilyco-ops commented

2026-08-12 07:48:16 +00:00

Member

One line in .ward/ward.yaml. Independent of #1001 and #1002, merges in any order.

The verb could not pass locally

ward exec aos-test ran go test -C aos-cli ./... with no -timeout, so Go's 600s default applied. The suite needs 699s on an M-series Mac, measured directly:

ok  forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/aos  699.477s

So the command the repo tells agents and humans to use for this module could not run to completion on the machine most likely to run it. It failed at 600.536s, which reads as a hang rather than a timeout unless you already know Go's default. It cost me a round of chasing a hang that was not there.

Why CI never caught it

The same step finishes in 4.462s on the runner (job 27640, ci / aos-cli-tests, log line 643). The gate stayed green the whole time the local verb was unusable.

That is not mass skipping. The suite has three t.Skip calls total and all are narrow (symlinks unavailable twice, one ps platform quirk). The runner is simply far faster at the git-heavy native-shadow tests than macOS is.

The change

-timeout 30m. Roughly 2.5x the measured local wall time, so a genuine hang still fails rather than hanging until the Ward or CI timeout. No effect on CI, which is nowhere near either bound.

Worth separate attention, not folded in here

A 60x local-to-CI gap on the same tests means ci / gate is a much weaker signal for this module than its name suggests.
A 12-minute unit suite is worth profiling on its own. I have a verbose run collecting per-test timings and will file that with the data rather than guess at it here.

🤖 Generated with Claude Code

One line in `.ward/ward.yaml`. Independent of #1001 and #1002, merges in any order. ## The verb could not pass locally `ward exec aos-test` ran `go test -C aos-cli ./...` with no `-timeout`, so Go's 600s default applied. The suite needs 699s on an M-series Mac, measured directly: ``` ok forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/aos 699.477s ``` So the command the repo tells agents and humans to use for this module could not run to completion on the machine most likely to run it. It failed at `600.536s`, which reads as a hang rather than a timeout unless you already know Go's default. It cost me a round of chasing a hang that was not there. ## Why CI never caught it The same step finishes in **4.462s** on the runner (job 27640, `ci / aos-cli-tests`, log line 643). The gate stayed green the whole time the local verb was unusable. That is not mass skipping. The suite has three `t.Skip` calls total and all are narrow (`symlinks unavailable` twice, one `ps` platform quirk). The runner is simply far faster at the git-heavy native-shadow tests than macOS is. ## The change `-timeout 30m`. Roughly 2.5x the measured local wall time, so a genuine hang still fails rather than hanging until the Ward or CI timeout. No effect on CI, which is nowhere near either bound. ## Worth separate attention, not folded in here * A 60x local-to-CI gap on the same tests means `ci / gate` is a much weaker signal for this module than its name suggests. * A 12-minute unit suite is worth profiling on its own. I have a verbose run collecting per-test timings and will file that with the data rather than guess at it here. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

coilyco-ops added 1 commit

2026-08-12 07:48:16 +00:00

fix(ward): give aos-test a timeout the suite can actually finish inside

ci / ward-doctor (pull_request) Successful in 12s

Details

ci / aos-cli-tests (pull_request) Successful in 31s

Details

ci / gate (pull_request) Successful in 1m0s

Details

3ec8f79627

`ward exec aos-test` ran `go test -C aos-cli ./...` with no `-timeout`, so Go's
600s default applied. The suite needs 699s on an M-series Mac, measured just
now:

    ok  forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/aos  699.477s

So the verb the repo tells agents and humans to use could not pass locally. It
failed at exactly 600.536s, which reads as a hang rather than a timeout unless
you already know the default.

CI never caught this because the same step finishes in 4.462s there (job 27640,
`ci / aos-cli-tests`). Nothing is being skipped: the suite has three `t.Skip`
calls, all narrow. The Linux container is simply that much faster at the
git-heavy native-shadow tests, so the gate stayed green while the local verb
was unusable.

30m leaves headroom without hiding a real hang.

The 60x gap and a 12-minute unit suite are both worth their own look. Filed
separately rather than folded in here.

Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>

coilyco-ops requested review from coilysiren

2026-08-12 07:48:16 +00:00

coilyco-ops referenced this pull request

2026-08-12 07:54:13 +00:00

Agent sessions pay ~1s of pyenv on every git call, which is why aos-test takes 11 minutes #1004