Skip to main content

page_within

Function page_within 

Source
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)>,
) -> Page
Expand 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.