pub const DEMAND_REQUESTS_PER_REPOSITORY_PER_POLL: u32 = 4;Expand description
Requests one demand poll costs, per repository, in steady state.
Four: the two run listings (QUEUED_RUN_STATUS and
IN_PROGRESS_RUN_STATUS), plus a job listing for each of the couple of
runs a repository has under way at any moment.
§Why this is a projection and not a measurement, and what bounds it
Under the previous owner decision this constant was 1 and it was exact: one
request per repository, always, because total_count on the runs query
answered the whole question. Counting jobs makes the cost depend on how many
runs are active, which is a number no constant can know. So this is the
steady-state figure the budget model prices, in the same spirit as
crate::rest::ACTIVITY_REQUESTS_PER_REPOSITORY_PER_REFRESH, which is also
a best case with a documented worse one.
The worst case is 2 + MAX_QUEUED_RUNS_PER_REPOSITORY_PER_POLL + MAX_IN_PROGRESS_RUNS_PER_REPOSITORY_PER_POLL, which is what
max_demand_requests_per_repository_per_poll returns, and it is bounded by
construction rather than by hope: the two caps are hard, and a repository
that reaches them says so through QueuedDemand::is_truncated rather than
spending more. crate::rest::BUDGET_SHARE_DIVISOR absorbs the gap between
the two figures — the projection is compared against half the documented
ceiling precisely so that the half nobody models has somewhere to go.
A repository is only at the worst case while it genuinely has that many runs in flight, which is also exactly when spending requests to scale correctly is worth more than saving them.