pub const MAX_ACTIVITY_FALLBACK_PAGES: usize = 4;Expand description
The most pages one repository’s in-progress count may walk when GitHub sends
no total_count.
crate::MAX_PAGES is the wrong ceiling for this walk, and the distinction
is a budget one rather than a stylistic one. MAX_PAGES exists to stop a
Link: rel="next" cycle looping forever; it is not a number anything
budgeted for. This walk is charged against
ACTIVITY_REQUESTS_PER_REPOSITORY_PER_REFRESH, which is one, and that
constant is what TargetCost projects and what f2 computes its add
refusals from.
The arithmetic is why the two cannot share a ceiling. At the 60-second
default a target refreshes 60 times an hour, so the projection budgets 60
requests for one repository’s activity count. A fallback allowed to reach
MAX_PAGES could spend 6,000 — more than the whole
HOURLY_REQUEST_CEILING, for a single repository’s count — which would
make every refusal f2 computes from the projection a fiction.
Four pages counts 400 in-progress runs exactly, at a worst case of 240
requests/hour against the ~2,500 BUDGET_SHARE_DIVISOR leaves as slack.
Past that the answer stops being exact and says so: the repository lands
in ActivityCount::truncated. That is what makes a bounded walk honest
rather than merely cheap — an unbounded walk and a silently-clipped one are
both wrong, in opposite directions.