[feature](lance) Support distance bounds in vector_search by Gabriel39 · Pull Request #68815 · apache/doris

Gabriel39 · 2026-10-09T06:20:10Z

What problem does this PR solve?

Issue Number: Closes #66493

vector_search() cannot currently restrict results by distance. This adds optional distance_lower_bound (inclusive) and distance_upper_bound (exclusive) parameters for single-vector Radius/Range Search on Lance tables.

The FE validates finite FLOAT bounds and their order, includes the range in EXPLAIN, and carries it through the external-search request. The BE applies the bounds through the existing pinned lance-c API after configuring the query vector, covering indexed and Flat Search splits, including appended data outside index coverage. The existing external-search schema version remains unchanged at 1.

Results retain the existing table columns and FLOAT _distance, prefilter semantics, offset, and Top-K cap. Bounds can be bound through prepared-statement parameters and are revalidated on each execution. Multi-vector distance bounds are rejected.

Bounded index search is limited to explicitly identified IVF_FLAT segments with both bounds present. Quantized or unknown index types and single-sided ranges fall back to exact fragment scans, reported as DISTANCE_RANGE_FALLBACK in EXPLAIN. This avoids pre-refinement quantization errors and the pinned index implementation’s finite sentinels for absent bounds, at the cost of additional scanning. Unbounded queries retain their index selection; indexed IVF_FLAT recall still depends on probed partitions.

Standalone BM25 is already delivered; the distributed BM25 statistics follow-up remains tracked separately in #67435.

Release note

Lance vector_search() supports optional lower and upper distance bounds for single-vector radius and range queries.

Validation

BE: rebuilt the current branch and passed all 68 LanceTableReader* tests under ASAN, including exact SQ threshold crossing, the finite FLT_MAX DOT endpoint, prefilter variants, and existing reader coverage.
FE: 76 tests passed across VectorSearchTableValuedFunctionTest, LancePreparedSearchTest, LancePreparedStatementTest, and LanceScanNodeTest, including repeated bound binding, invalid parameters, all index subtypes, and indexed/flat split selection.
Native reproduction: the pinned indexed paths drop both the SQ threshold-crossing row and the finite FLT_MAX DOT endpoint; exact Flat Search returns both. Added self-contained fixtures and reader coverage for these cases.
Native execution: 10 cases passed against the pinned lance-c revision, covering indexed/Flat Search, appended unindexed data, inclusive/exclusive bounds, empty results, prefiltering, and offset.
FE Checkstyle and clang-format 16 checks passed.
Added SQL regression coverage for range results, projected stored columns, filtering, offset, invalid bounds, and EXPLAIN. Its Groovy syntax compilation passed; the SQL suite has not yet run against a live Doris cluster and requires External Regression CI.

Check List (For Author)

Test
- Regression test added (execution pending CI)
- Unit Test
- Manual native execution test
Behavior changed:
- Yes: optional distance bounds on single-vector searches; existing unbounded queries retain their behavior.
Does this need documentation?
- Yes: bilingual 4.x Lance Catalog documentation: [docs](lance) Document radius and range vector search doris-website#4200.

Check List (For Reviewer who merge this PR)

Confirm the release note
Confirm test cases
Confirm document
Add branch pick label

hello-stephen · 2026-10-09T06:20:15Z

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

What problem was fixed (it's best to include specific error reporting information). How it was fixed.
Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
What features were added. Why was this function added?
Which code was refactored and why was this part of the code refactored?
Which functions were optimized and what is the difference before and after the optimization?

Gabriel39 · 2026-10-09T06:20:16Z

run buildall

Gabriel39 · 2026-10-09T06:20:23Z

/review

github-actions

Review complete at head 30fface8a2d5953d24db816300a1c323593891ec after three bounded static-review rounds and a final sweep of all 20 changed paths. I found two new issues: prepared SQL rejects placeholders for the new bounds (P2), and a lower-only maximal FLOAT bound loses an eligible row in a pinned Lance indexed path (P3). No user-specific review focus or existing inline blocker was present.

Goal, scope, and behavior: The FE parses optional finite FLOAT lower/upper bounds, compares them after FLOAT rounding, and sends optional Thrift fields with schema version 2; the BE validates and installs the range after the vector query. The lower endpoint is inclusive and the upper endpoint exclusive. Literal-bound, single-vector requests keep their values through split copies, indexed and flat scans, filters, projected rows, and the global TopK/OFFSET merge. The change is focused on query behavior, a fixture, and tests. The new matrix rejection matches the supported multi-vector shape. The two findings are the remaining functional gaps.

Concurrency and lifecycle: The FE builds fresh requests and copies them per split; the BE builds a scanner per reader. This adds no shared mutable state, lock order, static initialization, or new cleanup path. The pinned C API copies the local bound values before they leave scope. Explicit existing query_parallelism is the path that exposes the indexed endpoint issue. Scanner setter failures propagate as errors. Configuration and compatibility: no new runtime setting was added; version-2 range requests are rejected by older readers rather than silently losing bounds, while unbounded requests remain version 1. There is no production data write, transaction, EditLog, or persistent-state change.

Tests and output: The added FE unit tests inspect parsing, FLOAT rounding, Thrift presence/version, and multi-vector rejection. BE tests and a V3 indexed/appended fixture inspect validation, split coverage, filtering, and offset; the SQL suite checks exact endpoints, projected values, and Explain. Their expected values are consistent under static inspection. Coverage misses actual SQL PREPARE bound placeholders and maximal-finite lower-only indexed/flat parity, corresponding to the inline findings. I did not build or run tests under this review contract. The PR author reports BE, FE, and native runs; those are author claims, not independent validation, and the author says the live SQL suite is pending CI.

Observability and cost: Explain displays bound presence; BE returns explicit validation/native errors and existing scanner profiles remain available. No additional production metric appears necessary for this per-query option. Bounds add per-request parsing/copying and native range filtering before candidate truncation, with no separate persistent or broad allocation path identified. No other substantiated issue remains after checking numeric conditions, parallel indexed/flat paths, lifecycle, compatibility, and tests.

Gabriel39 · 2026-10-09T07:02:15Z

run buildall

Gabriel39 · 2026-10-09T07:02:16Z

/review

github-actions

Complete static review of PR #68815 at aaf2621. Two coverage rounds converged and the final sweep covered all 20 changed paths. One new P1 finding is inline: bounded IVF_SQ search can discard a true in-range row using its quantized score before exact refinement.

Existing comments 4227385313 (P2 prepared bound placeholders) and 4227385317 (P3 missing-bound indexed endpoint) still apply and are not reposted. The symmetric absent-lower endpoint case shares the latter's native sentinel root cause. No previously reported P0/P1 inline blocker applies to this head.

Critical checkpoints: The goal is single-vector Lance distance-range search. FE FLOAT parsing, multi-vector rejection, Thrift schema version 2, BE validation, scanner setup after nearest(), and split request copies are consistent; old BE rejects version 2 during rolling upgrade. Changes are focused on TVF, wire, reader, EXPLAIN, and tests. Scanner-local bounds introduce no new concurrency, lock, static-initialization, or ownership issue; Lance-C copies the bound values. There is no new configuration, transaction, production write, or persistence path. Indexed and flat execution were compared across bound presence, metrics, top-k/offset, refinement, and appended fragments; the lossy-index threshold issue is the remaining correctness defect. EXPLAIN exposes the configured range, and no separate observability or performance regression was substantiated. FE/BE unit and regression cases cover ordinary L2 IVF_FLAT, appended fragments, and invalid bounds, but do not cover the SQ threshold crossing. No result file was added; the new row and distance assertions are consistent with the fixture recipe on static inspection. Tests were inspected only; builds and tests were prohibited by the review prompt and were not run. The change does not touch committed-data visibility or delete bitmap behavior.

User focus: no additional focus points were provided. Review completion: complete, with the new P1 issue reported inline.

hello-stephen · 2026-10-09T09:37:26Z

FE UT Coverage Report

Increment line coverage 74.07% (20/27) 🎉
Increment coverage report
Complete coverage report

Gabriel39 · 2026-10-09T10:15:20Z

run buildall

Gabriel39 · 2026-10-09T10:15:28Z

/review

github-actions

Review complete at bc67e3b. One new P1 remains: a bounded vector_search request can run without its range on an older BE during rolling upgrade, returning rows outside the requested interval. The new comment is inline on the Thrift fields. Existing P1 comment 4227661849 (lossy-index range filtering) is resolved by the IVF_FLAT-only two-sided index gate; P3 comment 4227385317 (absent-upper FLT_MAX sentinel) is resolved by single-sided fragment fallback; P2 comment 4227385313 (prepared bounds) is resolved by the parser allow-list and repeated-binding path. No existing P0/P1 comment still applies to this head. There was no additional user-provided focus.

Critical checkpoints:

Goal, scope, and tests: FE parses FLOAT bounds, carries them through Thrift and split planning, and BE installs them after nearest(); this implements same-version bounded search but leaves the rolling-upgrade defect above. The production change is focused on the TVF, parser, planner, protocol, and Lance reader. FE/BE unit cases and the external regression cover parsing, binding, indexed and fragment paths, filters, offsets, and boundary fixtures. The external regression does not assert that a two-sided query actually selected the real IVF_FLAT index, so that integration check is less discriminating than the component checks. Tests and author-reported results were inspected, not executed here.
Concurrency and lifecycle: No new threads, shared mutable range state, locks, lock ordering, or cross-translation-unit static initialization were introduced. Each scanner receives its range after nearest() and uses the existing split and close lifecycle; no new resource-lifetime defect was substantiated.
Configuration and compatibility: No new configuration or dynamic-setting path was added. The new optional FE-to-BE Thrift fields need a version or capability gate for mixed-version execution (P1). No on-disk format, function-symbol, or persisted metadata change was introduced.
Parallel paths and conditions: Two-sided IVF_FLAT ranges may use indexed splits; single-sided and lossy/unknown-index ranges use exact fragment splits. BE disables index use for splits without segment UUIDs. Prepared execution rebinds bounds; finite FLOAT ordering, multi-vector rejection, filter, offset, and metric paths were checked. No additional correctness issue was substantiated.
Error handling, memory, and observability: FE and BE validate finite endpoints and return checked errors; the new bounds add no significant owned allocation. EXPLAIN reports range and index-fallback status; existing scan counters remain in use. No separate logging or metric defect was established.
Persistence, writes, and performance: This is a read-only search change, with no transaction, EditLog, write atomicity, or crash-recovery path. Exact fragment fallback can cost more than index search for unsafe ranges; that cost is documented, and no other performance regression was substantiated.

This was a static review under the no-build/no-test instruction. All 40 changed paths and every candidate were swept after two convergence rounds; all round-2 reviewers returned NO_NEW_VALUABLE_FINDINGS.

github-actions · 2026-10-09T10:30:26Z

    5: optional TVectorMetric metric
+    // FLOAT bounds: inclusive lower and exclusive upper.
+    6: optional double distance_lower_bound
+    7: optional double distance_upper_bound


[P1] Guard bounded searches across BE rolling upgrades. These new optional fields are the only distance filter, but vector_search() still sends schema version 1. A pre-change BE accepts that version, skips fields 6/7, and runs an unbounded nearest search; the FE's old-BE check only covers additional projected types. For example, distance_upper_bound=16 can return rows at distance 16 or above. Use a range-specific request version that old BEs reject, or require range-capable BEs before dispatch.

hello-stephen · 2026-10-09T13:52:30Z

FE UT Coverage Report

Increment line coverage 100.00% (35/35) 🎉
Increment coverage report
Complete coverage report

hello-stephen · 2026-10-09T14:53:25Z

FE Regression Coverage Report

Increment line coverage 80.00% (28/35) 🎉
Increment coverage report
Complete coverage report

np

Companion to apache/doris#68815. Merge the documentation with the implementation. Document `distance_lower_bound` and `distance_upper_bound` in the English and Chinese 4.x Lance Catalog guides, including FLOAT and squared-L2 semantics, expected results, filtering and offset order, Top-K limits, and prepared-statement bound parameters. Explain that only two-sided ranges on explicitly identified IVF_FLAT indexes use indexed search. Single-sided ranges and quantized or unknown index types fall back to exact Flat Search, with `DISTANCE_RANGE_FALLBACK` in EXPLAIN and potentially higher scan cost. Remove the schema-version upgrade requirement; the implementation retains the existing protocol version. Validation: the modified range sections compile as MDX in both locales, and `git diff --check` passes. A full website build was not run.

### What problem does this PR solve? Issue Number: Closes #66493 `vector_search()` cannot currently restrict results by distance. This adds optional `distance_lower_bound` (inclusive) and `distance_upper_bound` (exclusive) parameters for single-vector Radius/Range Search on Lance tables. The FE validates finite FLOAT bounds and their order, includes the range in EXPLAIN, and carries it through the external-search request. The BE applies the bounds through the existing pinned lance-c API after configuring the query vector, covering indexed and Flat Search splits, including appended data outside index coverage. The existing external-search schema version remains unchanged at 1. Results retain the existing table columns and FLOAT `_distance`, prefilter semantics, offset, and Top-K cap. Bounds can be bound through prepared-statement parameters and are revalidated on each execution. Multi-vector distance bounds are rejected. Bounded index search is limited to explicitly identified IVF_FLAT segments with both bounds present. Quantized or unknown index types and single-sided ranges fall back to exact fragment scans, reported as `DISTANCE_RANGE_FALLBACK` in EXPLAIN. This avoids pre-refinement quantization errors and the pinned index implementation’s finite sentinels for absent bounds, at the cost of additional scanning. Unbounded queries retain their index selection; indexed IVF_FLAT recall still depends on probed partitions. Standalone BM25 is already delivered; the distributed BM25 statistics follow-up remains tracked separately in #67435. ### Release note Lance `vector_search()` supports optional lower and upper distance bounds for single-vector radius and range queries. ### Validation - BE: rebuilt the current branch and passed all 68 `LanceTableReader*` tests under ASAN, including exact SQ threshold crossing, the finite FLT_MAX DOT endpoint, prefilter variants, and existing reader coverage. - FE: 76 tests passed across `VectorSearchTableValuedFunctionTest`, `LancePreparedSearchTest`, `LancePreparedStatementTest`, and `LanceScanNodeTest`, including repeated bound binding, invalid parameters, all index subtypes, and indexed/flat split selection. - Native reproduction: the pinned indexed paths drop both the SQ threshold-crossing row and the finite FLT_MAX DOT endpoint; exact Flat Search returns both. Added self-contained fixtures and reader coverage for these cases. - Native execution: 10 cases passed against the pinned lance-c revision, covering indexed/Flat Search, appended unindexed data, inclusive/exclusive bounds, empty results, prefiltering, and offset. - FE Checkstyle and clang-format 16 checks passed. - Added SQL regression coverage for range results, projected stored columns, filtering, offset, invalid bounds, and EXPLAIN. Its Groovy syntax compilation passed; the SQL suite has not yet run against a live Doris cluster and requires External Regression CI. ### Check List (For Author) - Test - [x] Regression test added (execution pending CI) - [x] Unit Test - [x] Manual native execution test - Behavior changed: - [x] Yes: optional distance bounds on single-vector searches; existing unbounded queries retain their behavior. - Does this need documentation? - [x] Yes: bilingual 4.x Lance Catalog documentation: apache/doris-website#4200. ### Check List (For Reviewer who merge this PR) - [ ] Confirm the release note - [ ] Confirm test cases - [ ] Confirm document - [ ] Add branch pick label

… planned ### What problem does this PR solve? Issue Number: None Related PR: apache#69581, apache#68707, apache#68815 Problem Summary: apache#69581 ports the Lance reader from the branch-4.2 snapshot cabcf45, where `_configure_vector_search()` passes the request's `use_index` to `lance_scanner_set_use_index()`. FE decides per split whether to use an index: a split it plans with index segments carries their UUIDs, and a split without them is meant to be searched flat. With `use_index = true` and no segments, Lance instead searches the split with the first index on the column in manifest order. That index need not be the one FE chose: when FE finds no index whose metric matches the query, it plans every split flat, and the snapshot BE still searched them with the mismatched index. On branch-4.2, apache#68815 also plans distance-range searches over quantized indexes (IVF_SQ) as flat fallback splits, because quantized distances can drop rows inside the range; the snapshot BE searches those with the index and returns too few rows. Fix: port the split-level rule of apache#68707. - `lance_scanner_set_use_index(scanner, segment_count > 0)`: a split with segments searches exactly those, a split without segments searches flat, and `LancePlannedFlatSearchFragmentCount` now matches what Lance does. - A split that carries index segments while the request sets `use_index = false` is rejected with InvalidArgument. FE plans segments only when `use_index` allows them, on branch-4.1 (4.1.4 onward) and branch-4.2 alike, so a 4.x FE never sends this combination. - Not ported: the rest of apache#68707 (searching historical versions, tags and branches; rejecting fragment ids missing from the snapshot; naming the snapshot in errors and the profile). That comes with the next 4.x catch-up. ### Release note None ### Check List (For Author) - Test: Unit Test - New, from apache#68707 (only master's `RuntimeState(TQueryOptions(), globals)` constructor differs): `LanceTableReaderVectorSearchTest.SplitWithoutIndexSegmentsSearchesFlat`, `LanceTableReaderVectorSearchTest.RejectsIndexSegmentsWhenUseIndexIsFalse`. - Changed as in apache#68707: `MultiVectorScoresFiltersOffsetsAndIndexedCoverage`, `MultiVectorTopOnePreservesPrecisionAndBatchIndependence` and `MultiVectorCosineMasksUndefinedRows` pass the index segments for their indexed cases (new helper `make_indexed_lance_range`) and check `LanceIndexPartitionsSearched`; `MultiVectorDefaultMetricIsConsistentAcrossFragments` checks that every split is searched flat. - All pass on macOS arm64 (ASAN) against master's pinned lance-c, with the Lance suites. With `use_index` taken from the request and the rejection removed, the two new cases fail. - Behavior changed: Yes, on the Lance path added by apache#69581: a vector split without index segments is searched flat even when `use_index` is true, and a split with segments under `use_index = false` is rejected. Master has no FE that plans Lance scans yet. - Does this need documentation: No Co-authored-by: zy-kkk <zhongyk10@gmail.com> Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

### What problem does this PR solve? Issue Number: None Related PR: apache#69581, apache#68815 Problem Summary: apache#69581 ports the Lance reader from the branch-4.2 snapshot cabcf45. After that snapshot, apache#68815 added `TVectorSearchParams.distance_lower_bound` (6) and `distance_upper_bound` (7) to branch-4.1 and branch-4.2: FLOAT bounds, inclusive lower and exclusive upper, which the 4.x FE fills for a single-vector `vector_search()` with distance bounds. apache#68815 kept the external-search `schema_version` at 1, so a BE cannot tell a bounded request from an unbounded one by version. A master BE without the fields ignored them and returned the unbounded top-k rows, for example rows with `_distance` below the lower bound. Fix: port the BE side of apache#68815. - `gensrc/thrift/PlanNodes.thrift`: add `6: optional double distance_lower_bound` and `7: optional double distance_upper_bound` to `TVectorSearchParams` with the 4.x comment. - `LanceTableReader::_validate_external_search_request()` rejects bounds on a multi-vector query (NotSupported), a bound that is not a finite FLOAT value (NaN, infinity, or beyond FLT_MAX), and a lower bound that is not below the upper bound at FLOAT precision (InvalidArgument), before the dataset is opened. - `_configure_vector_search()` narrows the bounds to FLOAT and installs them with `lance_scanner_set_distance_range()` after `lance_scanner_nearest()`, which clears any earlier range. A missing bound is passed as NULL (unbounded on that side). Requests without bounds are unchanged. Before: distance bounds sent by a 4.x FE were silently ignored. After: the reader returns only rows with lower <= _distance < upper, still capped by top_k and offset, and rejects invalid bounds. Compatibility (gensrc/AGENTS.md): fields 6 and 7 of `TVectorSearchParams` are `optional double distance_lower_bound` and `optional double distance_upper_bound` on the branch-4.2 (a7ae6f4) and branch-4.1 (3f911d0) heads, the same ids and types as here. branch-4.0 and branch-3.1 have no `TVectorSearchParams`, and on master the struct is new in apache#69581 with fields 1-5. No id is reused, and both fields are optional. `lance_scanner_set_distance_range()` is in master's lance-c pin (4fafcd64525), so only the BE changes. ### Release note None ### Check List (For Author) - Test: Unit Test - New (copied unchanged from apache#68815 except for master's `RuntimeState(TQueryOptions(), globals)` constructor): `LanceTableReaderVectorSearchTest.ValidatesDistanceRangeBeforeDatasetAccess`, `LanceTableReaderVectorSearchTest.AppliesDistanceBoundsAndOffset`, `LanceTableReaderVectorSearchTest.DistanceRangeFallbackPreservesExactScores`, `LanceTableReaderVectorSearchTest.DistanceRangeCoversIndexedAndAppendedFragments`. - Fixtures copied from d306323 (identical on the branch-4.2 head): `be/test/format_v2/table/lance/data/distance_range.lance` (11 files), `distance_range_dot.lance` (8 files), `distance_range_sq.lance` (8 files) and their description `be/test/format_v2/table/lance/distance_range_fixture.md`. - All pass on macOS arm64 (ASAN) against master's pinned lance-c, with the Lance suites. `DistanceRangeFallbackPreservesExactScores` needs the previous commit: without it the IVF_SQ fallback split is searched with the quantized index and loses its only row. With the range not installed, the three cases that read rows fail. - Behavior changed: Yes, on the Lance external-search path added by apache#69581: distance bounds are applied instead of ignored, and invalid bounds are rejected. Master has no FE that sends Lance search requests yet. - Does this need documentation: No Co-authored-by: Gabriel <liwenqiang@selectdb.com> Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

### What problem does this PR solve? Issue Number: None Related PR: apache#65730 apache#66608 apache#66805 apache#66841 apache#66999 apache#67005 apache#67011 apache#67110 apache#67268 apache#67289 apache#67325 apache#67650 apache#67921 apache#68028 apache#68335 apache#68375 apache#68615 apache#68690 Problem Summary: Port the Lance BE read path of branch-4.1/4.2 (as of branch-4.2 cabcf45) to master. Master links liblance_c but has no Lance reader: file_scan_operator keeps FORMAT_LANCE off FileScannerV2 and V1 has no Lance path, so every FORMAT_LANCE scan fails today. This change is BE only. The FE connector plugin and the regression suites follow separately, so nothing on master plans a Lance scan yet and the BE unit tests carry the proof. - Reader: be/src/format_v2/lance/* and format_v2/table/lance_reader.* (plain scans, vector and full-text search, Substrait and runtime filter pushdown, scalar index segments, COUNT(*) from metadata, LIMIT, profiles), copied from branch-4.2 except one local renamed for -Wshadow. - Hooks: FileFormat::LANCE and its exhaustive switches, FileScannerV2 dispatch, and fetch_table_schema for FORMAT_LANCE. Lance queries use FileScannerV2 whatever enable_file_scanner_v2 says, as ADBC and fluss do: there is no V1 Lance reader. The second phase of TopN lazy materialization reads Lance rows through dataset take_rows. - Row locations: GlobalRowLoacationV2 gets a version 1 layout with a 64-bit Lance row id (the version 0 layout is unchanged), PRequestBlockDesc.row_id becomes uint64 (varint, wire compatible), and the materialization operator and RowIdStorageReader decode and validate by version. - Thrift: the external search request body, TLanceFileDesc 4-6 and TExternalSearchRequest 2-4 with the branch-4.1/4.2 ids. - Core: PTypeDesc keeps NULL_TYPE for a NULL literal type, and the nullable serde reads an Arrow Null array as NULLs. - Nine lance_* BE configs, a BE-wide Lance session with an optional Foyer data cache and 10 lance_session_* metrics; macOS links IOKit. - Tests: the Lance BE unit tests and their fixtures, including the docker fixture all_types.lance that one of them reads. Under master's -ffile-prefix-map the session test locates its fixture from the repository root, and the reader tests shrink the data cache to 64 MiB under the UT temp dir: the default 100 GiB disk tier is 51200 block files that stay open for the rest of the test process. Not included: the MaterializationOperator::push timer fix (apache#69579), the Lance index metadata scanner, the FE side, regression suites, and the 4.x changes after cabcf45 (apache#68707, apache#68813, apache#68815). ### Release note Add nine lance_* BE configs and lance_session_* BE metrics. They take effect once the FE can plan Lance scans. ### Check List (For Author) - Test: Unit Test - BE UT: the Lance reader, nested Null, runtime filter and session suites, plus the row-location protocol and FileScannerV2 cases - Behavior changed: Yes. PRequestBlockDesc.row_id is uint64, and the second phase of TopN lazy materialization rejects row locations of an unknown version or size. - Does this need documentation: No (documented with the FE connector) Co-authored-by: zhangstar333 <zhangsida@selectdb.com> Co-authored-by: Gabriel <liwenqiang@selectdb.com> Co-authored-by: zhaobo wang <wangzhaobo957@gmail.com> Co-authored-by: jay <qingfengyouchen@163.com> Co-authored-by: FANNG <fanng@apache.org> Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>