pub const ACTIVITY_REQUESTS_PER_REPOSITORY_PER_REFRESH: u32 = 1;Expand description
Requests one in-progress workflow count costs, per repository.
Workflow runs are a per-repository resource. There is no organization-wide workflow-runs endpoint, so an organization pays this once per repository the App is installed on.
§This is the best case, not the worst one
One request is what a repository costs when GitHub sends total_count,
which is the ordinary answer from the workflow-runs endpoint and the reason
the figure is 1. When it is absent the count falls back to walking pages,
and that walk may spend up to MAX_ACTIVITY_FALLBACK_PAGES — so the true
worst case per repository per refresh is four, not one.
The gap is stated rather than modelled, deliberately, and the same way
RUNNER_INVENTORY_REQUESTS_PER_REFRESH states that a paginated inventory
costs more than the one request it claims. But it is worth naming here
because things are built on top of it: f1’s host show headroom and f2’s
add refusals both read this constant, so both are projecting the
best case. A target sitting at the edge of what f2 will allow could
overrun by up to 4x on repositories whose counts take the fallback.
BUDGET_SHARE_DIVISOR is what absorbs this: the projection is compared
against half the ceiling precisely so that the half this model does not
attempt to count has somewhere to go. The fallback is also bounded and
says when it was reached — a repository that walked to the ceiling lands
in ActivityCount::truncated — so an overrun is visible rather than
silent. That visibility, not the number 1, is what makes the projection
honest.