Rework dispatch capacity architecture beyond TTL mitigation #1191

New issue

Closed

opened 2026-07-13 20:04:46 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-07-13 20:04:46 +00:00

Member

Rework dispatch reservation architecture beyond the PR #1189 TTL mitigation.

Context:

PR #1189 was merged for #1188.
Kai reviewed the result and called out that PR #1189 is mitigation, not the requested architecture reflow.
The TTL is valid mitigation, but it still leaves the core design shaped around a prelaunch reservation that can consume repo capacity before an engineer is actually visible/running.

What #1189 covered:

Added a launch-confirmation TTL / stale-prelaunch behavior.
Taught list, dispatch-health, and reap to account for stale prelaunch starts better.
This reduces the duration of a hard stop when prelaunch wedges.

What is still required:

Rework the dispatch tracker architecture so prelaunch does not hold the same capacity token as a real visible engineer.
Split the state model and capacity model explicitly:
- intent/request accepted
- launch pending/preflight
- visible/running engineer
- failed/released terminal state
Repo/global capacity should be consumed by visible/running engineers, not by launch intents that have not yet produced a visible container/process.
If prelaunch needs backpressure, give it its own small queue/lease model separate from repo engineer slots.
A failed visibility confirmation should release or roll back the launch intent immediately, not wait for a TTL to make the symptom tolerable.
ward agent list, dispatch-health, reap, and reservation comments should all reflect this model: a launch intent is not a running engineer, and stale/failed prelaunch is not active capacity.
--override-reservation should not be needed to recover from a non-visible launch intent, because that state should not block repo capacity in the first place.

Acceptance:

A dispatch that never creates a visible engineer cannot block a repo's engineer slots, even briefly beyond the synchronous launch attempt boundary.
Capacity accounting has tests proving repo/global worker limits count visible/running workers separately from prelaunch intents.
Prelaunch backpressure, if retained, has its own bounded queue/lease tests and operator-visible terminology.
Reap/health/list tests cover the new state machine and no longer depend on a TTL as the primary correctness mechanism.
Docs explain the model in terms of launch intents vs running engineers, not one overloaded reservation concept.

Rework dispatch reservation architecture beyond the PR #1189 TTL mitigation. Context: - PR #1189 was merged for #1188. - Kai reviewed the result and called out that PR #1189 is mitigation, not the requested architecture reflow. - The TTL is valid mitigation, but it still leaves the core design shaped around a prelaunch reservation that can consume repo capacity before an engineer is actually visible/running. What #1189 covered: - Added a launch-confirmation TTL / stale-prelaunch behavior. - Taught list, dispatch-health, and reap to account for stale prelaunch starts better. - This reduces the duration of a hard stop when prelaunch wedges. What is still required: - Rework the dispatch tracker architecture so prelaunch does not hold the same capacity token as a real visible engineer. - Split the state model and capacity model explicitly: - intent/request accepted - launch pending/preflight - visible/running engineer - failed/released terminal state - Repo/global capacity should be consumed by visible/running engineers, not by launch intents that have not yet produced a visible container/process. - If prelaunch needs backpressure, give it its own small queue/lease model separate from repo engineer slots. - A failed visibility confirmation should release or roll back the launch intent immediately, not wait for a TTL to make the symptom tolerable. - `ward agent list`, `dispatch-health`, `reap`, and reservation comments should all reflect this model: a launch intent is not a running engineer, and stale/failed prelaunch is not active capacity. - `--override-reservation` should not be needed to recover from a non-visible launch intent, because that state should not block repo capacity in the first place. Acceptance: - A dispatch that never creates a visible engineer cannot block a repo's engineer slots, even briefly beyond the synchronous launch attempt boundary. - Capacity accounting has tests proving repo/global worker limits count visible/running workers separately from prelaunch intents. - Prelaunch backpressure, if retained, has its own bounded queue/lease tests and operator-visible terminology. - Reap/health/list tests cover the new state machine and no longer depend on a TTL as the primary correctness mechanism. - Docs explain the model in terms of launch intents vs running engineers, not one overloaded reservation concept.

coilyco-ops referenced this issue

2026-07-13 20:04:52 +00:00

Fix dispatch prelaunch reservation architecture #1188

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

2026-07-13 20:22:48 +00:00

Rework dispatch capacity architecture beyond TTL mitigation #1192

coilyco-ops commented

2026-07-13 20:24:12 +00:00

Author

Member

WARD-OUTCOME: submitted

details

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

felt: mechanical, but the intent/capacity split needed a second pass to keep brokered cleanup from leaking into direct launches.
confidence: high
surprises: the comment-length hook only liked the two-line version of one docstring.
follow-ups: none

WARD-OUTCOME: submitted <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped (review gate intentionally skipped because temporary ward default pending brokered QA) felt: mechanical, but the intent/capacity split needed a second pass to keep brokered cleanup from leaking into direct launches. confidence: high surprises: the comment-length hook only liked the two-line version of one docstring. follow-ups: none </details>