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:
parent
4be2279485
commit
01cba3c665
2 changed files with 104 additions and 3 deletions
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Reference in a new issue