runon replies after its inputs are captured

AF
3h ago
+3301-543

Accepted agent delivery; branch-keyed search descriptor included.


Summary by cubic

Delays runon bash launch replies until the remote runner confirms capture of its inputs, so callers never receive a task_id before the input files are copied.

  • The reply waits for the runner's first Accepted record or a settled refusal, staying pending across retries, drain signals, and cancellations without shortening blocking waits; a signal or expired deadline that lands after Accepted still returns the ordinary launch reply (or a recorded refusal's error), not the pending one.
  • The wait shares a 60-second deadline with the call's timeout budget; on expiry the reply returns the task_id with a warning that input files must stay untouched until the job is queued or running.
  • Snapshots report a "submitting" phase until acceptance instead of showing a not-yet-accepted job as queued or running; a task that settles before acceptance returns its saved outcome with advice (no in-flight warning), an accepted-and-finished task keeps its ordinary launch reply, and only live tasks carry the input-safety warning.
  • Capture-pending state is persisted in snapshots, so an AFT restart or disk recovery keeps the delayed reply and warning instead of handing back the task_id mid-capture, and capture-state reads honor a recorded Accepted even when they start after the deadline.
  • Terminal-status checks and live runon handoff tracking are centralized in the bridge for consistent plugin behavior; OpenCode and Pi extend their runon transport deadline so the delayed reply is not discarded, while local and legacy remote launches stay unchanged.
  • Tool schemas tell agents not to change or delete files a background command uses until it finishes.

RetriggerView in GreptileConfidence Score: 5/5

The changes since the previous review appear safe to merge.

Summary

Delays explicit runon launch replies until the runner confirms input capture, with a warning when capture remains pending.

  • Runon launches wait for the runner to capture their inputs.
  • Task status shows when the runner is capturing inputs.
  • OpenCode and Pi track runon tasks from their first reply.
  • Bash guidance tells agents to leave background command files alone.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Explicit runon launch] --> B[Wait for input capture]
    B --> C{Saved task state}
    C -->|Accepted without refusal| D[Ordinary launch reply]
    C -->|Refused| E[Return refusal]
    C -->|Ended before acceptance| F[Return saved outcome]
    C -->|Still pending at deadline or drain| G[Task handle with input warning]

Reviews (11) · Last reviewed commit: "mason: report a refusal after Accepted w..." · Reviewed by Greptile