fix(#2270): suppress bash-task completion wake already observed via status

A `status` or `run` call whose inline `wait_seconds` poll observes a
terminal task hands the caller the full result in that same tool
response. The completion wake fired unconditionally regardless,
producing a redundant `bash-task-<id>` inbox message for information
the agent already has.

Add a one-shot, in-memory wake-suppression registry in hive-bash-mcp's
runner: `wait_for_task` (shared by both BashRun's and BashStatus's
inline-wait paths) marks a task's wake suppressed the moment it
observes a terminal state; `run_task`'s completion handler consumes
that flag before calling `send_wake` and skips the wake if set.

In-memory only (daemon restart wipes it) — fine, since a task still
running across a restart is separately marked `interrupted` on boot
and gets its own fresh wake. Narrow best-effort race window between
the terminal write and the wake send; acceptable given this daemon's
existing best-effort delivery tolerance elsewhere.

docs/tools/bash.md updated to describe the new suppression behavior.
This commit is contained in:
atlas 2026-07-13 16:14:35 +02:00 committed by mara
commit 01cba3c665
2 changed files with 104 additions and 3 deletions

View file

@ -16,7 +16,8 @@ Stdout and stderr stream to `harness/bash-tasks/<id>.{out,err}`.
When the task completes (or times out, or the process errors), the
harness fires a wake with `from: "bash-task-<id>"`; the body contains
the exit code and last stdout lines. Handle the completion on a future
turn.
turn — unless `wait_seconds` already delivered the terminal result
inline, in which case the wake is suppressed (see `status` below).
* `timeout_secs` — kill the task after N seconds and mark it
`timed_out`. Omit for no timeout (runs until natural exit).
@ -51,6 +52,13 @@ finishes within the window the full status is returned immediately.
Useful to avoid a separate round-trip when the task is expected to
finish soon.
Any `status` call (waited or not) that observes a terminal task
suppresses that task's completion wake — you already have the result
in this response, so no redundant `bash-task-<id>` inbox message
follows (#2270). Narrow best-effort race: a `status`/`run` inline wait
that resolves in the same instant the task actually finishes can still
occasionally get both.
Tasks marked `interrupted` had their process killed by a harness
restart; a best-effort wake was still sent so the agent is not
silently blocked.