Repository navigation
Run long commands so that waiting ends with the command (for discussion) - #56
Open
anakanemison wants to merge 1 commit into
Open
anakanemison wants to merge 1 commit into
anakanemison wants to merge 1 commit into
Conversation
anakanemison
force-pushed
the
mschaller/d4-long-commands
branch
from
October 26, 2026 13:30
9cb8ee2 to
ab0e17a
Compare
Agents lose time to commands that block: a built program waiting on stdin,
a Bazel command queued behind another on the same server lock, and above
all waiting on a long build. Large projects make each more expensive, and
done now requires a clean build from a fresh output base.
The procedure's working-directory note gains a "Long commands" paragraph:
- Run a build or test suite in the foreground, with a timeout long enough
for it, when the command tool allows that long; it returns the moment the
command ends.
- If it may take longer, start it in the background with its log and PID
outside the workspace (so the log is not migrated), and wait with a loop
on `kill -0` of the saved PID, in 15-second slices, which ends as soon as
the command does.
- Never wait with `pgrep -f <name>`: the waiting command's own command line
contains the name, so it always finds itself. Don't sleep a fixed time on
a guess either.
- A second Bazel command in the same workspace waits for the first; run
built programs with </dev/null and a timeout.
It does not state the command tool's time limit: that is 10 minutes by
default in Claude Code, and settings raise it.
Measured in any2bazel-lab, on an earlier wording of this change ("run builds
and test suites that may take minutes in the background and poll them"):
agents followed it in eight of ten runs and waited badly. One waited 74
minutes on `while pgrep -f "yb_build.sh"`, which matched its own command
line, for a configure that had finished in 16 seconds. Four others spent 8
to 133 minutes in fixed sleeps of up to 700 s on builds that had already
finished. In all, 232 of the ten runs' minutes were commands still waiting
after their work had ended.
With the wording above, in six re-runs of the same projects, no agent
waited on `pgrep -f`, no sleep was longer than 60 s, and no waiting command
outlasted its work by more than 14 seconds. Waiting after work fell from 153
minutes to 6, and the QGIS migration took 121 minutes instead of 206. The
time-limit sentence was revised after those runs.
This is a proposal for discussion: how an agent should wait on long
commands is partly a property of the agent's tools, which the maintainers
may prefer to leave to them.
Lab-Proposal: P12
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
anakanemison
force-pushed
the
mschaller/d4-long-commands
branch
from
November 2, 2026 17:50
ab0e17a to
c3bdf76
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A new "Long commands" paragraph: run a build in the foreground with a long enough timeout where the command tool allows; otherwise in the background, waiting on
kill -0of the saved PID in short slices. Never wait withpgrep -f, which matches its own command line, and run built programs with</dev/nulland a timeout.With an earlier wording ("run in the background and poll"), ten any2bazel-lab runs spent 232 minutes waiting after the work had ended, including a 74-minute self-matching
pgrep -floop. With this wording, in six re-runs of the same projects, that fell from 153 minutes to 6, and QGIS took 121 minutes instead of 206. For discussion: how to wait is partly a property of the agent's tools.Stacked on #55 (tracking issue: #35).
pytest tests/: 186 passed (132 onmain). Lab proposal: P12.🤖 Generated with Claude Code