fix(view): /view/<run-id> budgets the page it renders and states the drop - #105
Merged
Conversation
…drop The route read with the streaming reader's 256 MB budget and inlined every kept byte into one document: a 708 MB session produced a 257 MB page no tab survives, silently missing 78% of the session. VIEW_BYTES (32 MB) now budgets the render, the response gzips, ?full=1 / ?bytes=N are the escape hatches, and every budgeted page (this route, view serve, --html) carries an amber truncation chip naming what was kept. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
lroolle
force-pushed
the
fix/view-budget
branch
from
September 2, 2026 04:24
3850c7f to
aae41fe
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Item 3 of Eric's 2026-08-31 batch: http://127.0.0.1:9317/view/9431ef5f-… (a very long work session) would not open.
Diagnosis (measured on that exact run)
The server never failed — it succeeded at the wrong thing.
/view/<run-id>read the trace with the streaming reader's budget (TAIL_BYTES= 256 MB) and inlined every kept byte ~1:1 into one HTML document:truncationNotice; the route discardedresult.truncated)Fix
VIEW_BYTES(32 MB) — a document budget, distinct from the streaming budget — applied at the route; the same run now serves a 33 MB page in ~5 s (verified against the real trace)?full=1/?bytes=N(MB) escape hatches, mirroring the CLI's--fullPageMeta.truncatedrenders an ambernewest X MB of Y MBheader chip (tip: dropped lines, unscanned older files); on/view/<run-id>the chip links?full=1.cctrace viewserve and--htmlpages carry the same chip — the terminal already said it, but a reader who got the URL never saw the terminalNot in this PR (follow-ups, ranked in the diagnosis)
Compact-on-render (stub superseded request bodies at render time — the only fix that keeps a whole 438-pair session visible in ~20-50 MB) and streaming NDJSON hydration (kills the giant string on both ends, incl. the one-frame WS
init). Filed as an issue.Verification
bun test888/0 (new: a 3 MB fixture through?bytes=1keeps the newest pair, drops the oldest, stampstruncated;?full=1restores everything and stamps nothing; the chip renders from meta and stays empty without it). Real-world: the exact failing run served through the new route — status 200, 33 MB decoded, 18 MB wire, truncation chip present.🤖 Generated with Claude Code