Revisit broker detach timing for forwarded engineer launches #1470

Closed
opened 2026-07-16 06:12:06 +00:00 by coilyco-ops · 3 comments
Member

Brokered engineer launch appears to detach later than expected. The expected model is that the director asks the broker, the broker validates/adopts the request, starts the host ward agent engineer process, records the dispatch artifact path/request id, then returns to the director once the host Ward binary is initialized and owned by the broker.

Observed from coilyco-flight-deck/ward#1468:

  • The director command returned only after the host launch path reached container bring-up/visibility territory.
  • The dispatch artifact ended with wrote launch env file, spawned drain-on-exit waiter, and ward dispatch broker: launch completed.
  • The engineer container then failed almost immediately during in-container prelaunch because /usr/local/bin/ward was not an executable. The broker had already treated the launch as completed because the container handoff was visible enough.

Problem:

  • The current detach point makes the foreground director command wait through host launch checks and container creation rather than detaching at the host Ward process handoff.
  • That couples the interactive surface to launch progress and blurs the meaning of a successful broker response: is it broker-accepted, host-process-started, container-visible, or engineer-running?

Design question:

  • Decide the intended broker contract explicitly. If the broker should return when the host Ward binary is initialized, the returned result should mean accepted by broker and host launch process started, with later failures surfaced through dispatch artifacts, issue comments, ward agent list, and ward agent logs.
  • If the broker intentionally waits for container visibility, rename/document the success state and make the logs say which milestone was waited for.

Acceptance criteria:

  • Broker detach milestone is documented in docs/agent-dispatch-broker.md or the current lifecycle docs.
  • The broker response/log wording distinguishes broker acceptance, host Ward process start, container visibility, and engineer harness start.
  • Tests pin the detach behavior so future changes do not silently move the boundary.
  • Failure reporting still leaves a durable artifact path and enough context for directors to recover without a live foreground command.
Brokered engineer launch appears to detach later than expected. The expected model is that the director asks the broker, the broker validates/adopts the request, starts the host `ward agent engineer` process, records the dispatch artifact path/request id, then returns to the director once the host Ward binary is initialized and owned by the broker. Observed from coilyco-flight-deck/ward#1468: - The director command returned only after the host launch path reached container bring-up/visibility territory. - The dispatch artifact ended with `wrote launch env file`, `spawned drain-on-exit waiter`, and `ward dispatch broker: launch completed`. - The engineer container then failed almost immediately during in-container prelaunch because `/usr/local/bin/ward` was not an executable. The broker had already treated the launch as completed because the container handoff was visible enough. Problem: - The current detach point makes the foreground director command wait through host launch checks and container creation rather than detaching at the host Ward process handoff. - That couples the interactive surface to launch progress and blurs the meaning of a successful broker response: is it broker-accepted, host-process-started, container-visible, or engineer-running? Design question: - Decide the intended broker contract explicitly. If the broker should return when the host Ward binary is initialized, the returned result should mean `accepted by broker and host launch process started`, with later failures surfaced through dispatch artifacts, issue comments, `ward agent list`, and `ward agent logs`. - If the broker intentionally waits for container visibility, rename/document the success state and make the logs say which milestone was waited for. Acceptance criteria: - Broker detach milestone is documented in `docs/agent-dispatch-broker.md` or the current lifecycle docs. - The broker response/log wording distinguishes broker acceptance, host Ward process start, container visibility, and engineer harness start. - Tests pin the detach behavior so future changes do not silently move the boundary. - Failure reporting still leaves a durable artifact path and enough context for directors to recover without a live foreground command.
Author
Member

WARDED_WORKFLOW: blocked 🛑

details

manual close/update snapshot at 2026-07-23T04:38:26Z is newer than the latest ward acknowledgement at 2026-07-23T04:35:21Z

This action is blocked until the feedback is visibly acknowledged.

— Codex, via ward agent

WARDED_WORKFLOW: blocked 🛑 <details><summary>details</summary> manual close/update snapshot at 2026-07-23T04:38:26Z is newer than the latest ward acknowledgement at 2026-07-23T04:35:21Z This action is blocked until the feedback is visibly acknowledged. </details> <!-- ward-agent-signature --> — Codex, via `ward agent`
Author
Member

WARDED_WORKFLOW: #1516

details

Review summary: review gate intentionally skipped (temporary ward default pending brokered QA).

workflow: pull-request-and-merge; review summary: review gate intentionally skipped (temporary ward default pending brokered QA)

Felt: the recovered patch mapped cleanly onto current main after the outage; the hook only required comment-length cleanup. Confidence: high. Surprises: none beyond the PR acknowledgement gate. Follow-up: brokered QA can restore the temporary review default.

WARDED_WORKFLOW: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/1516 <details><summary>details</summary> Review summary: review gate intentionally skipped (temporary ward default pending brokered QA). workflow: pull-request-and-merge; review summary: review gate intentionally skipped (temporary ward default pending brokered QA) Felt: the recovered patch mapped cleanly onto current main after the outage; the hook only required comment-length cleanup. Confidence: high. Surprises: none beyond the PR acknowledgement gate. Follow-up: brokered QA can restore the temporary review default. </details>
Author
Member

WARDED_WORKFLOW: reservation-released

release details

Run finished with WARDED_WORKFLOW: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/1516.

ward container reap released container engineer-codex-ward-1470 (--harness codex): the terminal outcome supersedes the reservation, so a later redispatch no longer needs --override-reservation.

Outcome summary: #1516

— Codex, via ward agent

<!-- ward-agent-reservation-released --> WARDED_WORKFLOW: reservation-released <details><summary>release details</summary> Run finished with `WARDED_WORKFLOW: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/1516`. `ward container reap` released container `engineer-codex-ward-1470` (`--harness codex`): the terminal outcome supersedes the reservation, so a later redispatch no longer needs `--override-reservation`. **Outcome summary:** https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/1516 </details> <!-- ward-agent-signature --> — Codex, via `ward agent`
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-flight-deck/ward#1470
No description provided.