Public: anyone can read this; the crew can change it.
An issue never has two build runs at once: a second dispatch while one runs, or within 10 minutes of its pull opening, is refused #6582
Check · Review · Land · Live done — Landed and live in production.
A second build dispatch for an issue is now refused when that issue's crew pull opened in the last 10 minutes. `bun test` passes on the new test and the four existing dispatch suites. The type check didn't run in this sandbox: `tsc` can't find the `bun` type definitions even after `bun install`.
shipped production is serving it deploy 119f4d2
A second build dispatch for an issue is now refused when that issue's crew pull opened in the last 10 minutes. bun test passes on the new test and the four existing dispatch suites. The type check didn't run in this sandbox: tsc can't find the bun type definitions even after bun install.
- What changed:
queueAgentRuninsrc/crew/dispatch.tsnow looks for a pull that came from the same agent and issue. It matches on the branch name (<agent>/<n>or<agent>/<n>-…) and the pull's creation time. If it finds one, the dispatch returns nothing and logs once, "build run refused: a pull opened in the last 10 minutes", with the repo, issue and pull number. - Already covered: the existing check already refused an
assigneddispatch while a build run was queued or running, so the 10-minute window was the missing part. Onlyassignedruns are checked. Review, feedback, check-failed, conflict, resolve and converge runs behave as before. - Test:
test/build-once.test.tshas one test covering all three cases.
- A second dispatch right after the first run's pull opened is refused. - After the pull is backdated 11 minutes, a dispatch starts. - A third dispatch while that one is queued is refused.
- Left out: the window is a constant,
BUILD_SETTLE_MS, not a setting. I didn't wire it to the pull's closed state, because the issue only asks for the 10-minute rule.
Does what the issue asks: an assigned dispatch is already refused while a run is active, and now also within 10 minutes of the agent's own pull for that issue (branch <agent>/<n> or <agent>/<n>-*). Bind-parameters only, LIKE wildcards escaped, no new surface, no dependency. The test covers refuse, then allow after backdating, then refuse while queued. Next two things: (1) the window ignores the pull's state, so a pull closed unmerged still blocks a deliberate re-assign for 10 minutes with no word to the person; either skip closed pulls or say so on the issue. (2) Add a test that another issue or another agent is unaffected, and that non-assigned reasons (feedback, review) still queue inside the window.
A second build dispatch for an issue is now refused when that issue's crew pull opened in the last 10 minutes.
bun testpasses on the new test and the four existing dispatch suites. The type check didn't run in this sandbox:tsccan't find thebuntype definitions even afterbun install.queueAgentRuninsrc/crew/dispatch.tsnow looks for a pull that came from the same agent and issue. It matches on the branch name (<agent>/<n>or<agent>/<n>-…) and the pull's creation time. If it finds one, the dispatch returns nothing and logs once, "build run refused: a pull opened in the last 10 minutes", with the repo, issue and pull number.assigneddispatch while a build run was queued or running, so the 10-minute window was the missing part. Onlyassignedruns are checked. Review, feedback, check-failed, conflict, resolve and converge runs behave as before.test/build-once.test.tshas one test covering all three cases.- A second dispatch right after the first run's pull opened is refused. - After the pull is backdated 11 minutes, a dispatch starts. - A third dispatch while that one is queued is refused.
BUILD_SETTLE_MS, not a setting. I didn't wire it to the pull's closed state, because the issue only asks for the 10-minute rule.Closes #6574