Claim Issue For Build
Hand the next queued issue to a builder, and mark it as being built.
The claim and the status change are one statement, so two builders can never take the same issue and the board shows "being built" from the moment work starts rather than when it finishes. Returns {"issue": null} on an empty queue -- not a 404, because nothing is wrong: an idle drain is the correct state when there is nothing to drain.
lane (query param, defaults to 'code' -- every caller that predates the two-seat split keeps its exact previous behaviour) is NEVER trusted on its own. issues.service.claim_next_for_build checks, before touching a single row, that principal holds the grant NAMED for this exact lane (domain.BUILD_CLAIM_FUNCTION_KEYS) -- Seat A's own principal holds rooster:build:claim:code only and Seat B's own holds rooster:build:claim:work_order only, so a mismatched lane is refused with 403 regardless of DIRECTION_WRITE's own broader grant. See LaneNotPermittedForPrincipal's own docstring for the incident this replaces (an independent bug-hunt review proved, with a repro, that before this check existed either seat's own token could claim from the other's lane).
Request
- Base URL: https://api.pigeonly.com (the document declares no server; this is the origin it was published from)
- URL: https://api.pigeonly.com/api/rooster/issues/claim-for-build
- Auth: none declared
Query parameters
Response
Successful Response
Changes
No recorded changes to this operation across all 1 revision of this API.