Repository navigation
Description
Finding
Open PR #927 (Jules, for #811) fixes the oversized-layout() poison path by falling back to program.view() cropped to the requested size — but the fallback result is never checked against presentation_bytes, the very limit the branch exists to enforce. A world whose default view is also large (or not a screen) gets an over-limit presentation delivered as success.
Found by the pr-diff-review job reviewing PR #927, 2026-10-25. PR #927 is still open, so this can be folded into it or fixed immediately after it lands; the code quoted is from the PR head (4d33369c), pkgs/id/src/world/actor.rs, WorldCommand::ViewAt handler.
Evidence
- The layout branch triggers only when
text.len() > self.core.limits.presentation_bytes(default 8192,pkgs/id/src/world/mod.rs:91), incrementsview_failures, and falls back. - Fallback, non-screen case:
Ok(Some(fallback_text))is returned for anyprogram.view()text thatparse_surfacedoesn't recognize as a screen — with no length check at all. A guest whoseview()returns a >8192-byte non-screen presentation sails through. - Fallback, screen case: the surface is cropped with
surface.fit(width, height)and re-serialized, but the serialized result is never compared topresentation_bytes. Screens may be up toMAX_SCREEN_WIDTH×MAX_SCREEN_HEIGHT= 120×50 = 6000 cells (pkgs/id/src/world_presentation.rs:15-19), each cell a JSON object — a dense cropped screen is far over 8192 bytes. On serialization failure the code doesunwrap_or(fallback_text), returning the original unchecked text. - The PR's own test (
an_oversized_layout_degrades_to_a_view_fallback_and_recovers,pkgs/id/src/world/tests.rs) covers only a tiny 10×10 fallback view, so none of these cases is exercised. - Related bound disagreement in the same PR: the
ClientFrame::Resizehandler inpkgs/id/src/world_session/mod.rsfirst validateswidth/heightagainst 500×200 (error text: "viewport dimensions must be width 1..=500 and height 1..=200"), then silently clamps the stored viewport toMAX_SCREEN_WIDTH/MAX_SCREEN_HEIGHT= 120/50. A client that resizes to, say, 300×100 is told that size is legal but is actually served a 120×50 view. Which bound is meant to govern — and whether silently shrinking a legal resize is the intended id phase-9: a joiner's resize (up to 500x200) can permanently poison a world via the guest layout() call exceeding presentation_bytes #811 mitigation — deserves an explicit verdict in the same triage.
Why it matters
#811 is about a guest presentation exceeding the byte limit breaking the world. A fallback that can itself exceed the limit reintroduces the over-limit delivery on the exact path meant to prevent it — consumers sized for presentation_bytes (SSH/web surfaces) receive unbounded presentations, and the failure mode moves somewhere harder to diagnose.
Acceptance criteria
- The ViewAt fallback result (cropped screen serialization, non-screen text, and the serialization-failure path) is checked against
presentation_bytesbefore being returned; an over-limit fallback degrades to an error (counted like other view failures) instead of an over-limit success. - A regression test with a fallback view that is itself over the limit (dense screen and/or non-screen text) proves the world still does not deliver it and does not poison.
- The Resize bound disagreement (validation allows 500×200, the stored viewport is silently clamped to 120×50) is resolved — one governing bound, and the error text matches it — or documented as intentional.
— filed by the pr-diff-review job (PR #927, relating to #811); triage via the repo-health queue pilot.
Activity
dezren39 commentedon Oct 26, 2026
🤖 Agent note · filed
dezren39 commentedon Oct 31, 2026
🤖 Agent note · picked up
21 remaining items
dezren39 commentedon Nov 3, 2026
🤖 Agent note · parked
queue/8051-942-viewat-fallback-bound(commit 2a5736f), PR fix(id/world): bound the oversized-layout ViewAt fallback by presentation_bytes (#942) #5061 opened. The ViewAt fallback result (cropped screen serialization, non-screen text, and the serialization-failure path) is now checked againstpresentation_bytes; an over-limit fallback incrementsview_failuresand returnsErr("world presentation exceeds N bytes"). The Resize clamp verdict (intentional per F14.2) is documented inworld_session/mod.rs.cargo test -p id --lib oversized14 passed;cargo test -p id --lib world::tests164 passed, 0 failed (new regression tests: over-limit fallback text, over-limit cropped fallback screen).dezren39 commentedon Nov 3, 2026
🤖 Agent note · parked
queue/8051-942-viewat-fallback-bound) already implements the ViewAt fallback bound; I re-verified the diff against the acceptance criteria (all three fallback paths bound by presentation_bytes, serialization failure no longer returns unchecked text, two regression tests asserting Err + program_healthy + view_failures, Resize clamp documented per F14.2) and the laptop test results recorded on task 8051 (cargo test -p id --lib oversized: 14 passed; world::tests: 164 passed).basic: production line limit (2500)check on PR fix(id/world): bound the oversized-layout ViewAt fallback by presentation_bytes (#942) #5061 was still QUEUED/pending after a 5-minute poll. Resume = fresh check of PR fix(id/world): bound the oversized-layout ViewAt fallback by presentation_bytes (#942) #5061, merge when green, complete task 8051 as fixed_merged (PR fix(id/world): bound the oversized-layout ViewAt fallback by presentation_bytes (#942) #5061 closes issue id(world): PR #927's oversized-layout fallback never checks its own result against presentation_bytes (#811) #942).queue/8051-942-viewat-fallback-boundfix(id/world): bound the oversized-layout ViewAt fallback by presenta…
dezren39 commentedon Nov 3, 2026
Done (task 8051, lane code-e): PR #5061 squash-merged as
75f5f1472060cfc777b7fb2e72b1e0344d5e0875(2026-11-03T18:56:26Z); this issue auto-closed. The ViewAt fallback is now bounded bypresentation_byteson all three paths (cropped serialization, non-screen text, serialization failure), with regression tests inpkgs/id/src/world/tests.rsand the Resize clamp verdict documented inworld_session/mod.rs. Evidence: line-limit check pass on the PR; laptopcargo test -p id --lib oversized14 passed andworld::tests164 passed; Codex disposition recorded on PR #5061 (usage-limit failure, zero inline findings).