Do not leave transient reservation dispatch comments on issues #1207

New issue

Closed

opened 2026-07-13 22:25:43 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-07-13 22:25:43 +00:00

Member

Ward reservation and dispatch-status comments are transient control-plane state. They should not remain as historical issue discussion once they are no longer live.

Problem:

failed dispatch comments like WARD-DISPATCH: failed record momentary capacity/prelaunch facts that are useless days later
reservation / queued comments are useful while they are the active hold, but they should be cleaned up or collapsed when the hold is released
these comments add noise to issues and make future agents read stale operational telemetry as if it were durable discussion

Required behavior:

keep only live reservation / queued state on the issue while it is needed for coordination
when a reservation is released, successful, failed-before-launch, or otherwise no longer active, remove the transient comment or replace it with the smallest durable state needed for correctness
failed dispatch telemetry should go to local logs or a structured cache/log artifact, not permanent issue comments
issue comments that remain for durable workflow outcomes must use the standard WARDED_WORKFLOW header, but transient reservation markers should not remain in the thread
make the cleanup idempotent so a retry or reaper can safely remove stale transient comments

Acceptance criteria:

a failed dispatch caused by capacity/prelaunch limits leaves no permanent issue comment
a released reservation / queued marker is removed or collapsed after the run reaches a terminal state
active reservations remain visible enough for current single-node coordination until the issue-backed state refactor replaces them
tests cover failed-before-launch cleanup and released-reservation cleanup

Related: coilyco-flight-deck/ward#1205.

Ward reservation and dispatch-status comments are transient control-plane state. They should not remain as historical issue discussion once they are no longer live. Problem: - failed dispatch comments like WARD-DISPATCH: failed record momentary capacity/prelaunch facts that are useless days later - reservation / queued comments are useful while they are the active hold, but they should be cleaned up or collapsed when the hold is released - these comments add noise to issues and make future agents read stale operational telemetry as if it were durable discussion Required behavior: - keep only live reservation / queued state on the issue while it is needed for coordination - when a reservation is released, successful, failed-before-launch, or otherwise no longer active, remove the transient comment or replace it with the smallest durable state needed for correctness - failed dispatch telemetry should go to local logs or a structured cache/log artifact, not permanent issue comments - issue comments that remain for durable workflow outcomes must use the standard WARDED_WORKFLOW header, but transient reservation markers should not remain in the thread - make the cleanup idempotent so a retry or reaper can safely remove stale transient comments Acceptance criteria: - a failed dispatch caused by capacity/prelaunch limits leaves no permanent issue comment - a released reservation / queued marker is removed or collapsed after the run reaches a terminal state - active reservations remain visible enough for current single-node coordination until the issue-backed state refactor replaces them - tests cover failed-before-launch cleanup and released-reservation cleanup Related: coilyco-flight-deck/ward#1205.

coilyco-ops referenced this issue from a pull request that will close it,

2026-07-13 22:51:17 +00:00

Do not leave transient reservation dispatch comments on issues #1211

coilyco-ops commented

2026-07-13 22:52:15 +00:00

Author

Member

WARD-OUTCOME: submitted

details

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

retrospective: the cleanup felt surgical after the tracker delete path settled down.
confidence: high.
surprises: GitLab and Shortcut delete support stays best-effort without parent ids.
follow-ups: watch for any stale thread readers that still assume transient comments are durable state.

WARD-OUTCOME: submitted <details><summary>details</summary> workflow: pull-request-and-merge; review summary: review gate intentionally skipped by temporary ward default pending brokered QA retrospective: the cleanup felt surgical after the tracker delete path settled down. confidence: high. surprises: GitLab and Shortcut delete support stays best-effort without parent ids. follow-ups: watch for any stale thread readers that still assume transient comments are durable state. </details>