Skip to content

A full brick build disagrees with its own raw field inside the band -- up to 0.263 on random documents, and a Move leaves those bricks stale #649

Description

@leonardoaraujosantos

A full brick build of a document disagrees with that document's own raw field (clay_eval_points) at in-band samples. This is on main, before #648; #648 only made it reachable from undo.

Measured

benchmarks/undo_bound_oracle_probe with RV_RAWCHECK builds each random document's brick cache from nothing and compares every in-band (|raw| <= 0.12) sample of a built brick with clay_eval_points at the same point, flagging anything off by more than 2e-3 (far above the fp16 step at that range). Probe linked against main at c62d521 (#646 merged, before #647/#645/#648), and again against main + #645/#647/#648 -- identical numbers:

sweep documents off worst
seeds 1..1500, plain 21 of 1,500 0.0310 (seed 978)
seeds 5001..6500, rich 62 of 1,500 0.2632 (seed 6043)

The seeds #648's review named:

seed mode in-band samples off worst
933 plain 125 0.01052
5111 rich 1,219 0.18938
5128 rich 683 0.07375

Why it matters: the forward Move already leaves these bricks

RV_FORWARD does a host Move segment, dirties exactly what clay_layer_move_surface_regions reports, refills, and compares with a rebuild on a saved copy. On main:

  • seed 933 (plain): 8 bricks differ
  • seed 5229 (plain): 3 bricks differ
  • seed 5229 (rich): 6 bricks differ

Before #648 an undo of that Move refilled the whole node, which happened to hide the disagreement. #648 narrows the undo to the grab's support, so the undo now leaves the same bricks the Move does: 5 of 3,000 random undo/redo trials (1,500 plain, 1,500 rich), 1 to 8 bricks each (a sixth, 5128, leaves 13 on main too).

Which side is wrong

#648's review checked each of those bricks: the values the narrowed refill KEPT match the raw field to the fp16 step; the full REBUILD is the one that is off. So the defect is in the build path (cull / seed / brick fill of a whole document), not in the undo bound or in the Move's reported regions.

Reproduce

cmake -S . -B build/probe -DCLAY_BUILD_BENCHMARKS=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build/probe --target undo_bound_oracle_probe --parallel 8
RV_RAWCHECK=1 build/probe/undo_bound_oracle_probe 933 1        # plain
RV_RAWCHECK=1 build/probe/undo_bound_oracle_probe 5111 1 r     # rich
RV_FORWARD=1  build/probe/undo_bound_oracle_probe 933 1
RV_FORWARD=1  build/probe/undo_bound_oracle_probe 5229 1 r
RV_RAWCHECK=1 build/probe/undo_bound_oracle_probe 1 1500       # the sweep

The probe drives the C ABI only, so it links against any revision for an A/B. RV_VERBOSE traces the fixture. Background: openspec/changes/archive/2026-09-23-bound-an-undone-grab-by-its-support/tasks.md, "What review found".

Activity

  1. added a commit that references this issue on Sep 23, 2026
  2. leonardoaraujosantos commented on Oct 4, 2026

    @leonardoaraujosantos
    ContributorAuthor

    Fixed by #680 (merged in 441af73).

  3. leonardoaraujosantos commented on Oct 4, 2026

    @leonardoaraujosantos
    ContributorAuthor

    Reopening: this was closed by mistake. #680 fixed mechanism B (squashed placements culled as distances) and says itself it is part of #649, not a fix for it. Mechanism A remains: the #335 chain-pad envelope applies its N = 75 value below 75 contributors, leaving 9 documents off in the rich sweep (worst 0.0170) and 21 in the plain sweep (worst 0.0310). Fixing it trades against the #335 performance win and needs the iPad gate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions