pub fn page_within(
messages: &[Message],
rendered: &Rendered,
dropped: usize,
dropped_thinking: i64,
before: Option<&str>,
turns: u32,
budget: usize,
budget_key: &'static str,
cap: Option<(usize, &SessionSlot)>,
) -> PageExpand description
page, with the whole turns it carries held to budget bytes.
A page of twenty turns is unbounded in bytes, and the first page is
what a seat switch waits on: a few large turns made one 5 MB, which is
seconds over a network and milliseconds locally. A more answer is held
the same way ([server] more_page_cap_kb): its page contract is whole
turns too, so one large turn crossed whole and a single page could be tens
of megabytes. So the newest page is cut where the budget runs out, at a
turn boundary - a client draws turns, and a turn cut in half is one it
cannot place. The handle it carries is the first kept turn’s, so more
walks the history above it as it always did.
The bytes counted are the bytes SERVED: each candidate is bounded by
cap first, exactly as the page would have been after the cut. Measuring
the raw records would make the page’s size follow a payload the client
never receives, and a seat with a few multi-MB records would keep one
turn where the capped page fits many.
The newest turn is served even when it alone is over the budget: a
budget that answered with no page would draw the seat empty, and one that
split the turn would hand a client half of it. usize::MAX is no budget.
budget_key is the forge.toml key the budget came from, named on a cut:
two caps share the default, and a line that did not say which one moved
would mislead.