builds: track queue time separately from build duration#13080
Draft
ericholscher wants to merge 6 commits into
Draft
builds: track queue time separately from build duration#13080ericholscher wants to merge 6 commits into
ericholscher wants to merge 6 commits into
Conversation
ericholscher
force-pushed
the
claude/build-queued-duration-tracking-YbGsv
branch
from
959decd to
7f97dab
Compare
ericholscher
force-pushed
the
claude/build-queued-duration-tracking-YbGsv
branch
from
7f97dab to
850ac09
Compare
The build duration (`length`) is measured from when the task actually starts running on a builder, so time spent waiting in the queue no longer inflates it. Expose the queued time via a new `Build.queue_time` property and a `queued` field in the v3 API, and base the API `finished` timestamp on the execution start (`task_executed_at`) instead of the trigger time.
Rename the v3 API field from `queued` to `queue_time` so it reads unambiguously as a duration in seconds rather than a build status/state, matching the `Build.queue_time` property. Also make the docstring state the unit (seconds) explicitly.
Drop a redundant guard in the v3 `finished` computation (``date`` is always set, so the fallback is never empty). Add an API test asserting queue time is reported separately and that ``finished`` is based on the execution start, not the trigger time.
Replace the computed `Build.queue_time` property with a stored `IntegerField` so the total queue wait is queryable for historical builds and cheap to aggregate. It's set in `before_start` from the original trigger date (`date`) to when the task starts running, so it captures the full wait even across retries (`date` is never reset). Add a migration and update the v2 build payload mock to include `date`.
`queue_time` is now a real model field, so the explicit IntegerField declaration is redundant; ModelSerializer generates it from Meta.fields.
The addons hosting (v1) response embeds the build serializer, which now includes the `queue_time` field. Update the expected-response fixture.
ericholscher
force-pushed
the
claude/build-queued-duration-tracking-YbGsv
branch
from
850ac09 to
d1128c5
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Builds can spend time waiting in the queue before a builder picks them up. That wait was previously invisible and impossible to reconstruct for a build that ran a while ago.
Decisions
Stored field vs. computed property. Queue time is
task_executed_at - date, which could be a computed property. We store it as a real column instead so it's queryable and cheap to aggregate over historical builds — that querying ability was the whole motivation, and a property can't provide it.Measured from the original trigger. It's measured from
date(set once at creation, never reset on retries) rather than per-attempt, so it captures the total wait even when a build is retried.Duration is intentionally untouched.
lengthis already measured from when the task starts running, so it never included queue time. Storing queue time separately keeps it that way — queue wait never inflates the reported duration.finishednow derives from execution start. It's computed fromtask_executed_at + duration(falling back todatefor builds predatingtask_executed_at), so the queue wait isn't counted toward the finish timestamp.Scope
This PR adds and populates the column going forward. Backfilling the value onto existing builds is split into a stacked PR (#13083) so the one-time data migration can be reviewed and reverted independently.
Notes for reviewers
0073adds the column (before_deploy).🤖 Generated by the Claude Code AI agent.