Indexer: fix price-window has_more at band floor (in-band slice complete, book continues outside band) #270

New issue

2026-06-02T06:59:57Z

PlasticDigits commented

2026-06-02 06:59:57 +00:00

(Migrated from gitlab.com)

Summary

Fix has_more semantics on GET /api/v1/pairs/{addr}/limit-book when price_from + price_to are set (price-window mode, GitLab #267). The returned orders[] slice is correct; the bug is that has_more: true is emitted when the walk stops at the band floor even though all in-band orders fit in one page and only out-of-band book tail remains below (bids) or above (asks).

Parent feature: #267 (closed). Consumers: #268 (ladder placement uses a single price-window fetch with limit=100), any integrator paginating on has_more.

Current codebase

indexer/src/api/limit_book_lcd.rs
- fetch_limit_book_page (~L108–L182): paginated head→tail walk; has_more = current.is_some() is correct because every visited node is returned.
- order_in_price_window (~L399–L436): classifies each row as in-band (Some(true)), above-band skip (Some(false)), or past band (None).
- fetch_limit_book_price_window (~L438–L538): walks the chain, collects in-band rows, stops on past_band or page cap. Today it sets has_more = current.is_some() (~L531) — same rule as full-book pagination, which conflates “more chain nodes exist” with “more in-band rows remain for this window.”
indexer/src/api/pairs.rs — get_pair_limit_book (~L1069–L1106) routes price_from/price_to to fetch_limit_book_price_window.
indexer/tests/api_limit_book_insert_hints.rs — price-window HTTP case (~L268–L279) uses mock book 1@2.0 → 2@1.5 → 3@1.5 → 4@1.0 (tail at band floor, no nodes below band). Asserts !has_more — passes today but does not cover the false-positive path.
frontend-dapp/src/hooks/useLimitLadderPlacementPlan.ts — single getPairLimitBookPage with price window (limit: 100); uses orders only, not has_more today, but spec-compliant clients and future pagination will.
Docs: docs/integrators.md § Insert hints & price window, docs/limit-orders.md, docs/adr/0002-limit-book-surfacing.md.

Bug mechanism (two exit paths)

past_band break: On first below-band (bid) / above-band (ask) row, the loop sets past_band = true and breaks before current = next. current still holds that out-of-band order id → current.is_some() → has_more: true even though the in-band slice is complete.
Page cap at band floor: If orders.len() == cap on the last in-band row, the while orders.len() < cap && !past_band exits without fetching the next node. current points at the first out-of-band successor → has_more: true without any in-band rows left.

Example (bids): chain 2.0 → 1.5 → 1.5 → 1.0 → 0.5, window [1.5, 1.0], limit=10. Returns orders 2,3,4 correctly; today has_more: true because id 5 @ 0.5 remains on-chain (should be false).

Why this is needed

has_more is the contract for “fetch another page with after_order_id.” A false positive forces spurious LCD-heavy pages, confuses integrators, and mirrors the pagination-gap hazard class from #267 (clients may treat trailing book depth as unfetched in-band depth).
#268 ladder preflight assumes one price-window response spans the ladder band; wrong has_more breaks trust in indexer completeness signals even when orders are complete.
Full-book pagination semantics must not leak into price-window mode; the window is a band filter, not “next segment of the global book.”

Constraints / guardrails

Do not change which orders are returned, band inclusivity, bid/ask bound rules, LIMIT_BOOK_LCD_QUERY_BUDGET, or LCD query counting.
has_more for price window means: “another page may return additional in-band orders for the same price_from/price_to.” Not “the FIFO chain continues outside the band.”
next_after_order_id when has_more: true must remain the keyset cursor for the next in-band page (last returned order id), unchanged from #267.
fetch_limit_book_page (no price window) behavior unchanged.
insert-hints resolver is out of scope (separate pagination_gap semantics).
Document the distinction in integrators.md if behavior is clarified for price-window mode.

Relevant files

indexer/src/api/limit_book_lcd.rs (fetch_limit_book_price_window, order_in_price_window)
indexer/src/api/pairs.rs
indexer/tests/api_limit_book_insert_hints.rs (extend) and/or indexer/tests/api_limit_book_lcd_mock.rs
docs/integrators.md, docs/limit-orders.md (price-window has_more definition)
Optional: frontend-dapp only if adding defensive handling (not required for indexer fix)

Recommended direction

Define stop reason at end of fetch_limit_book_price_window: StoppedBecause::PastBand | PageFull | ChainEnd | Budget (enum or booleans).
has_more rules (price window only):
- PastBand or ChainEnd → has_more: false (in-band slice complete for this walk).
- PageFull → has_more: true only if the walk stopped solely due to cap and the next unprocessed node could still be in-band (still above-band skips on bids are not “more pages of results”).
- When PageFull on the last in-band row and the successor is already known to be out-of-band (peek one row or classify without returning it), set has_more: false.
Minimal fix for the reported bug: has_more = current.is_some() && !past_band plus handle cap-at-floor by either one-step lookahead after filling cap or continuing the loop until past_band or current.is_none() without pushing (classification-only), staying within budget.
Add a dedicated mock book with in-band + below-band tail (and symmetric ask case) asserting orders unchanged and has_more: false.
Add cap < in-band depth case asserting has_more: true and correct next_after_order_id.

Acceptance criteria

Price window returns has_more: false when the full in-band slice fits one page and the walk reaches the first out-of-band row (bid below price_to, ask above price_to).
Price window returns has_more: false when the in-band slice ends at chain tail inside the band.
Price window returns has_more: true only when more in-band orders exist beyond limit for the same band (second page returns remaining in-band rows only).
orders[], prices, and ordering unchanged vs current behavior (regression on existing #267 tests).
Paginated limit-book without price_from/price_to unchanged.
integrators.md states price-window has_more means “more in-band rows,” not “more book outside the band.”

Test plan — all paths

Scenario	Expect
Bid window; in-band rows then below-band tail; `limit` ≥ in-band count	All in-band orders; `has_more: false`
Ask window; in-band rows then above-band tail; `limit` ≥ in-band count	Same
Bid window; tail order at `price_to`; no below-band nodes	`has_more: false` (existing mock)
Empty band (no in-band rows); walk skips above-band only	`orders: []`, `has_more: false` when past band or chain end
In-band depth > `limit`	Page 1: `has_more: true`, valid `next_after_order_id`; page 2 with `after_order_id`: rest of in-band only, then `has_more: false`
`limit` equals in-band count; next node out-of-band	`has_more: false` (cap-at-floor regression)
`after_order_id` mid-band continuation	Second page consistent with full-band fetch
Broken link / side mismatch	Existing 400/500 semantics unchanged

Test plan — attack / abuse / hack vectors

Vector	Expect
Spurious pagination loop — client trusts `has_more` and hammers `after_order_id` after band complete	After fix, loop terminates; no unbounded in-band-empty pages
LCD budget exhaustion — adversarial deep above-band skip before band	Still bounded by 101 queries; no extra queries from false `has_more` alone
Misleading completeness — UI treats `has_more` as “band incomplete”	Fix prevents false degraded/ladder states when `orders` already complete
Rate-limit amplification — false positives on LCD-heavy router	Fewer redundant `limit-book` window requests per integrator
Cap=1 pagination — many in-band rungs	Only `limit` rows per page; `has_more` true until band exhausted; no duplicate order ids across pages

Verification criteria

cargo test -p indexer api_limit_book_insert_hints (or new price_window_has_more test) green, including new below-band tail fixtures (bid + ask).
Existing insert_hints_and_price_window_http and api_limit_book_lcd_mock / api_limit_book_deep still pass.
cargo clippy -p indexer --all-targets -- -D warnings clean.
Manual curl against mock/local: window [1.5,1.0] on book with 0.5 tail → has_more: false, three orders.
integrators.md updated with one sentence on price-window has_more semantics.

## Summary Fix **`has_more`** semantics on **`GET /api/v1/pairs/{addr}/limit-book`** when **`price_from`** + **`price_to`** are set (price-window mode, GitLab **#267**). The returned **`orders[]`** slice is correct; the bug is that **`has_more: true`** is emitted when the walk stops at the **band floor** even though **all in-band orders fit in one page** and only **out-of-band** book tail remains below (bids) or above (asks). Parent feature: **#267** (closed). Consumers: **#268** (ladder placement uses a single price-window fetch with `limit=100`), any integrator paginating on **`has_more`**. --- ## Current codebase - **`indexer/src/api/limit_book_lcd.rs`** - **`fetch_limit_book_page`** (~L108–L182): paginated head→tail walk; **`has_more = current.is_some()`** is correct because every visited node is returned. - **`order_in_price_window`** (~L399–L436): classifies each row as in-band (`Some(true)`), above-band skip (`Some(false)`), or past band (`None`). - **`fetch_limit_book_price_window`** (~L438–L538): walks the chain, collects in-band rows, stops on **`past_band`** or page **`cap`**. Today it sets **`has_more = current.is_some()`** (~L531) — same rule as full-book pagination, which conflates “more chain nodes exist” with “more **in-band** rows remain for this window.” - **`indexer/src/api/pairs.rs`** — **`get_pair_limit_book`** (~L1069–L1106) routes **`price_from`/`price_to`** to **`fetch_limit_book_price_window`**. - **`indexer/tests/api_limit_book_insert_hints.rs`** — price-window HTTP case (~L268–L279) uses mock book **1@2.0 → 2@1.5 → 3@1.5 → 4@1.0** (tail at band floor, **no** nodes below band). Asserts **`!has_more`** — passes today but **does not cover** the false-positive path. - **`frontend-dapp/src/hooks/useLimitLadderPlacementPlan.ts`** — single **`getPairLimitBookPage`** with price window (`limit: 100`); uses **`orders` only**, not **`has_more`** today, but spec-compliant clients and future pagination will. - **Docs:** `docs/integrators.md` § Insert hints & price window, `docs/limit-orders.md`, `docs/adr/0002-limit-book-surfacing.md`. ### Bug mechanism (two exit paths) 1. **`past_band` break:** On first below-band (bid) / above-band (ask) row, the loop sets **`past_band = true`** and **`break`s** before **`current = next`**. **`current`** still holds that out-of-band order id → **`current.is_some()`** → **`has_more: true`** even though the in-band slice is complete. 2. **Page cap at band floor:** If **`orders.len() == cap`** on the last in-band row, the **`while orders.len() < cap && !past_band`** exits **without** fetching the next node. **`current`** points at the first out-of-band successor → **`has_more: true`** without any in-band rows left. **Example (bids):** chain `2.0 → 1.5 → 1.5 → 1.0 → 0.5`, window `[1.5, 1.0]`, `limit=10`. Returns orders 2,3,4 correctly; today **`has_more: true`** because id **5 @ 0.5** remains on-chain (should be **`false`**). --- ## Why this is needed - **`has_more`** is the contract for “fetch another page with **`after_order_id`**.” A false positive forces **spurious LCD-heavy pages**, confuses integrators, and mirrors the **pagination-gap** hazard class from **#267** (clients may treat trailing book depth as unfetched in-band depth). - **#268** ladder preflight assumes one price-window response spans the ladder band; wrong **`has_more`** breaks trust in indexer completeness signals even when **`orders`** are complete. - Full-book pagination semantics must **not** leak into price-window mode; the window is a **band filter**, not “next segment of the global book.” --- ## Constraints / guardrails - **Do not change** which orders are returned, band inclusivity, bid/ask bound rules, **`LIMIT_BOOK_LCD_QUERY_BUDGET`**, or LCD query counting. - **`has_more`** for price window means: **“another page may return additional in-band orders for the same `price_from`/`price_to`.”** Not “the FIFO chain continues outside the band.” - **`next_after_order_id`** when **`has_more: true`** must remain the keyset cursor for the **next in-band page** (last returned order id), unchanged from **#267**. - **`fetch_limit_book_page`** (no price window) behavior **unchanged**. - **`insert-hints`** resolver is out of scope (separate **`pagination_gap`** semantics). - Document the distinction in **`integrators.md`** if behavior is clarified for price-window mode. --- ## Relevant files - `indexer/src/api/limit_book_lcd.rs` (`fetch_limit_book_price_window`, `order_in_price_window`) - `indexer/src/api/pairs.rs` - `indexer/tests/api_limit_book_insert_hints.rs` (extend) and/or `indexer/tests/api_limit_book_lcd_mock.rs` - `docs/integrators.md`, `docs/limit-orders.md` (price-window `has_more` definition) - Optional: `frontend-dapp` only if adding defensive handling (not required for indexer fix) --- ## Recommended direction 1. **Define stop reason** at end of **`fetch_limit_book_price_window`**: `StoppedBecause::PastBand | PageFull | ChainEnd | Budget` (enum or booleans). 2. **`has_more` rules (price window only):** - **`PastBand`** or **`ChainEnd`** → **`has_more: false`** (in-band slice complete for this walk). - **`PageFull`** → **`has_more: true`** only if the walk stopped solely due to **`cap`** and the next unprocessed node could still be in-band (still above-band skips on bids are not “more pages of results”). - When **`PageFull`** on the last in-band row and the successor is already known to be out-of-band (peek one row or classify without returning it), set **`has_more: false`**. 3. Minimal fix for the reported bug: **`has_more = current.is_some() && !past_band`** plus handle **cap-at-floor** by either one-step lookahead after filling **`cap`** or continuing the loop until **`past_band`** or **`current.is_none()`** without pushing (classification-only), staying within budget. 4. Add a dedicated mock book with **in-band + below-band tail** (and symmetric **ask** case) asserting **`orders` unchanged** and **`has_more: false`**. 5. Add **cap < in-band depth** case asserting **`has_more: true`** and correct **`next_after_order_id`**. --- ## Acceptance criteria - Price window returns **`has_more: false`** when the full in-band slice fits one page and the walk reaches the first out-of-band row (bid below **`price_to`**, ask above **`price_to`**). - Price window returns **`has_more: false`** when the in-band slice ends at chain tail inside the band. - Price window returns **`has_more: true`** only when **more in-band orders** exist beyond **`limit`** for the same band (second page returns remaining in-band rows only). - **`orders[]`**, prices, and ordering unchanged vs current behavior (regression on existing **#267** tests). - Paginated **`limit-book`** without **`price_from`/`price_to`** unchanged. - **`integrators.md`** states price-window **`has_more`** means “more in-band rows,” not “more book outside the band.” --- ## Test plan — all paths | Scenario | Expect | |----------|--------| | Bid window; in-band rows then below-band tail; `limit` ≥ in-band count | All in-band orders; **`has_more: false`** | | Ask window; in-band rows then above-band tail; `limit` ≥ in-band count | Same | | Bid window; tail order at **`price_to`**; no below-band nodes | **`has_more: false`** (existing mock) | | Empty band (no in-band rows); walk skips above-band only | **`orders: []`**, **`has_more: false`** when past band or chain end | | In-band depth > `limit` | Page 1: **`has_more: true`**, valid **`next_after_order_id`**; page 2 with **`after_order_id`**: rest of in-band only, then **`has_more: false`** | | `limit` equals in-band count; next node out-of-band | **`has_more: false`** (cap-at-floor regression) | | `after_order_id` mid-band continuation | Second page consistent with full-band fetch | | Broken link / side mismatch | Existing 400/500 semantics unchanged | --- ## Test plan — attack / abuse / hack vectors | Vector | Expect | |--------|--------| | **Spurious pagination loop** — client trusts **`has_more`** and hammers **`after_order_id`** after band complete | After fix, loop terminates; no unbounded in-band-empty pages | | **LCD budget exhaustion** — adversarial deep above-band skip before band | Still bounded by **101** queries; no extra queries from false **`has_more`** alone | | **Misleading completeness** — UI treats **`has_more`** as “band incomplete” | Fix prevents false degraded/ladder states when **`orders`** already complete | | **Rate-limit amplification** — false positives on LCD-heavy router | Fewer redundant **`limit-book`** window requests per integrator | | **Cap=1 pagination** — many in-band rungs | Only **`limit`** rows per page; **`has_more`** true until band exhausted; no duplicate order ids across pages | --- ## Verification criteria - `cargo test -p indexer api_limit_book_insert_hints` (or new `price_window_has_more` test) green, including new below-band tail fixtures (bid + ask). - Existing **`insert_hints_and_price_window_http`** and **`api_limit_book_lcd_mock`** / **`api_limit_book_deep`** still pass. - `cargo clippy -p indexer --all-targets -- -D warnings` clean. - Manual **`curl`** against mock/local: window `[1.5,1.0]` on book with **0.5** tail → **`has_more: false`**, three orders. - **`integrators.md`** updated with one sentence on price-window **`has_more`** semantics.

Brouie commented

2026-06-02 13:28:21 +00:00

(Migrated from gitlab.com)

mentioned in merge request !735

Brouie commented

2026-06-02 13:29:03 +00:00

(Migrated from gitlab.com)

Fixed #270. Branch qa/270-price-window-has-more off main, commit 8e0a53e, MR !735. Indexer-only, no wasm/contract change.

Root cause confirmed in fetch_limit_book_price_window: it used has_more = current.is_some() (the full-book pagination rule), so on a price window it reported has_more=true whenever the chain continued past the band — even when the whole in-band slice already fit one page. The two exit paths in the issue both hit it: the past_band break leaves current pointing at the first out-of-band node, and a page-cap at the band floor leaves current pointing at the out-of-band successor.

Fix (price window only; fetch_limit_book_page untouched):

past_band -> has_more=false (book is price-ordered, so the in-band region is done). Zero extra LCD query, just the boolean flips.
chain end -> has_more=false.
page full -> peek the one successor; has_more=true only if it classifies in-band. The peek is one LCD query, gated on the 101 budget: if the budget is already spent it stays true (bounded over-report — next page returns the remaining in-band rows or one empty past-band page, then false).
next_after_order_id stays the last returned in-band id; orders[], band rules, the budget constant, and query counting are unchanged.

Acceptance criteria:

has_more=false when the in-band slice fits one page and the walk reaches the first out-of-band row -> price_window_has_more_excludes_out_of_band_tail scenario 1 (bid, below-band tail 5@0.5 -> orders 2,3,4, has_more false) and scenario 2 (ask, above-band tail 14@2.0 -> 11,12,13, has_more false).
has_more=false when the in-band slice ends at chain tail inside the band -> existing insert_hints_and_price_window_http case (1@2.0->2->3->4, window [1.5,1.0], tail 4@1.0 at the floor, no node below) still returns 3 orders + has_more false.
has_more=true only when more in-band rows exist beyond limit -> scenario 4 (bid, limit=2: page1 has_more true cursor=3; page2 after_order_id=3 -> [4] then false) and scenario 7 (ask twin).
orders[]/prices/ordering unchanged vs current behavior -> #267 regression suites green (below).
paginated limit-book without price_from/price_to unchanged -> fetch_limit_book_page is byte-for-byte untouched; api_limit_book_lcd_mock + api_limit_book_deep cover the full-book route and pass.
integrators.md states price-window has_more = "more in-band rows", not "more book outside the band" -> added.

Verification criteria:

cargo test -p cl8y-dex-indexer --test api_limit_book_insert_hints -> 5 passed (incl. below-band-tail bid AND above-band-tail ask through both exit paths).
insert_hints_and_price_window_http and api_limit_book_lcd_mock (5) / api_limit_book_deep (1) still pass.
[~] clippy: zero warnings in the two files I touched (limit_book_lcd.rs, the test). I did NOT get a clean crate-wide clippy -p cl8y-dex-indexer --all-targets -- -D warnings — same host-toolchain drift I flagged on #267 (pre-existing lints in orderbook_sim.rs/oracle.rs/parser.rs: is_multiple_of, dead code, matches!). None are mine. Still worth that crate-wide clippy cleanup issue.
manual mock/local check: I did this as an end-to-end HTTP test through the axum route rather than a hand-typed curl — window [1.5,1.0] on the 0.5-tail book returns exactly orders 2,3,4 and has_more=false (scenario 1). Same layer the criterion points at (mock/local). If you want a literal curl against localnet with real on-chain orders placed below the band, say the word and I'll set that up too.
integrators.md updated.

Attack/abuse vectors:

spurious pagination loop -> terminates after fix (past_band/chain-end false; over-report bounded).
LCD budget exhaustion -> price_window_has_more_budget_exhaustion_over_reports asserts a deep all-in-band book at limit=100 makes exactly 101 book queries with the peek suppressed (no 102nd), has_more=true, cursor=last id. So the peek never breaches the budget.
I also added LCD query-count asserts to the normal paths: past_band adds 0 peek queries (6 total on the tail book), a page-full in-band peek adds exactly 1 (5 total). That nails the "zero extra queries on past_band / one on peek" guardrail.

One behavior note: on a page-full stop the peek validates the successor, so a broken/wrong-side immediate successor now surfaces its corrupt-book 400 one page earlier than the full-book route did. Same integrity check the walk already runs on every node; a healthy book never hits it. Documented in the fn doc-comment.

Ran the diff through an adversarial multi-agent review before pushing — correctness lens found no defect and all guardrails held; the test-coverage gaps it flagged (ask peek path, budget over-report branch, query-count assertion) are the extra tests above.

Needs your review/merge on !735, then close. @PlasticDigits

Fixed #270. Branch qa/270-price-window-has-more off main, commit 8e0a53e, MR !735. Indexer-only, no wasm/contract change. Root cause confirmed in fetch_limit_book_price_window: it used has_more = current.is_some() (the full-book pagination rule), so on a price window it reported has_more=true whenever the chain continued past the band — even when the whole in-band slice already fit one page. The two exit paths in the issue both hit it: the past_band break leaves current pointing at the first out-of-band node, and a page-cap at the band floor leaves current pointing at the out-of-band successor. Fix (price window only; fetch_limit_book_page untouched): - past_band -> has_more=false (book is price-ordered, so the in-band region is done). Zero extra LCD query, just the boolean flips. - chain end -> has_more=false. - page full -> peek the one successor; has_more=true only if it classifies in-band. The peek is one LCD query, gated on the 101 budget: if the budget is already spent it stays true (bounded over-report — next page returns the remaining in-band rows or one empty past-band page, then false). next_after_order_id stays the last returned in-band id; orders[], band rules, the budget constant, and query counting are unchanged. Acceptance criteria: - [x] has_more=false when the in-band slice fits one page and the walk reaches the first out-of-band row -> price_window_has_more_excludes_out_of_band_tail scenario 1 (bid, below-band tail 5@0.5 -> orders 2,3,4, has_more false) and scenario 2 (ask, above-band tail 14@2.0 -> 11,12,13, has_more false). - [x] has_more=false when the in-band slice ends at chain tail inside the band -> existing insert_hints_and_price_window_http case (1@2.0->2->3->4, window [1.5,1.0], tail 4@1.0 at the floor, no node below) still returns 3 orders + has_more false. - [x] has_more=true only when more in-band rows exist beyond limit -> scenario 4 (bid, limit=2: page1 has_more true cursor=3; page2 after_order_id=3 -> [4] then false) and scenario 7 (ask twin). - [x] orders[]/prices/ordering unchanged vs current behavior -> #267 regression suites green (below). - [x] paginated limit-book without price_from/price_to unchanged -> fetch_limit_book_page is byte-for-byte untouched; api_limit_book_lcd_mock + api_limit_book_deep cover the full-book route and pass. - [x] integrators.md states price-window has_more = "more in-band rows", not "more book outside the band" -> added. Verification criteria: - [x] cargo test -p cl8y-dex-indexer --test api_limit_book_insert_hints -> 5 passed (incl. below-band-tail bid AND above-band-tail ask through both exit paths). - [x] insert_hints_and_price_window_http and api_limit_book_lcd_mock (5) / api_limit_book_deep (1) still pass. - [~] clippy: zero warnings in the two files I touched (limit_book_lcd.rs, the test). I did NOT get a clean crate-wide `clippy -p cl8y-dex-indexer --all-targets -- -D warnings` — same host-toolchain drift I flagged on #267 (pre-existing lints in orderbook_sim.rs/oracle.rs/parser.rs: is_multiple_of, dead code, matches!). None are mine. Still worth that crate-wide clippy cleanup issue. - [x] manual mock/local check: I did this as an end-to-end HTTP test through the axum route rather than a hand-typed curl — window [1.5,1.0] on the 0.5-tail book returns exactly orders 2,3,4 and has_more=false (scenario 1). Same layer the criterion points at (mock/local). If you want a literal curl against localnet with real on-chain orders placed below the band, say the word and I'll set that up too. - [x] integrators.md updated. Attack/abuse vectors: - spurious pagination loop -> terminates after fix (past_band/chain-end false; over-report bounded). - LCD budget exhaustion -> price_window_has_more_budget_exhaustion_over_reports asserts a deep all-in-band book at limit=100 makes exactly 101 book queries with the peek suppressed (no 102nd), has_more=true, cursor=last id. So the peek never breaches the budget. - I also added LCD query-count asserts to the normal paths: past_band adds 0 peek queries (6 total on the tail book), a page-full in-band peek adds exactly 1 (5 total). That nails the "zero extra queries on past_band / one on peek" guardrail. One behavior note: on a page-full stop the peek validates the successor, so a broken/wrong-side immediate successor now surfaces its corrupt-book 400 one page earlier than the full-book route did. Same integrity check the walk already runs on every node; a healthy book never hits it. Documented in the fn doc-comment. Ran the diff through an adversarial multi-agent review before pushing — correctness lens found no defect and all guardrails held; the test-coverage gaps it flagged (ask peek path, budget over-report branch, query-count assertion) are the extra tests above. Needs your review/merge on !735, then close. @PlasticDigits

PlasticDigits commented

2026-06-02 14:19:58 +00:00

(Migrated from gitlab.com)

mentioned in commit d8ed85583e

mentioned in commit d8ed85583e9b37ef7889c04d40158aa83d979778

PlasticDigits (Migrated from gitlab.com) closed this issue

2026-06-02 14:19:59 +00:00

Sign in to join this conversation.