Get Build

Build-specific details with optional task sub-object.

The task field is None for undispatched builds (task_id IS NULL in factory_builds).

The status field is the build's effective current status — the EffectiveBuildStatus vocabulary — computed server-side from the freshest authoritative source:

• Pre-dispatch (task_id IS NULL): computed from factory_builds.cancelled_at — "cancelled" when set, else "pending". Neither word is stored; the timestamp is the only persisted pre-dispatch state.
• Dispatched: tasks.status ("running", "completed", "failed", "cancelled"), with "timed_out" reconstructed from the persisted footprint of an execution timeout (status='failed' + error_class='timeout'). A submit-time dispatch_timeout is a different failure — the build never observably started — and reads as "failed".
• On cancel responses: Build Coordinator's returned status, which is fresher than the local row (which lags until BC's callback lands), put through the same derivation — BC's timed_out surfaces as "timed_out", agreeing with what a subsequent GET reconstructs once the callback persists the footprint. The field never carries a word outside the effective vocabulary.

Staleness: after handoff the field tracks tasks.status, which only advances when Build Coordinator's terminal callback lands. When callbacks are disabled (no callback base URL configured — a supported worker configuration), the post-handoff status stays at the last persisted value (typically "running") indefinitely; a cancel response is then the only place a fresher coordinator-reported status appears.