[zy-kkk]

What problem does this PR solve?

Issue Number: close #68625

Related PR: #68453 (time travel, tags, branches and managed versioning for Lance table scans)

Problem Summary:

vector_search() and full_text_search() always searched the latest version of main, and their table argument rejected FOR VERSION AS OF, @tag and @branch. A search could not be reproduced against a released tag, compared across versions, or run on an experimental branch.

Both TVFs now take four optional properties, with the semantics of the table syntax from #68453:

Property	Value	Table syntax	Combines with
version	positive integer	FOR VERSION AS OF N	branch
timestamp	yyyy-MM-dd HH:mm:ss[.SSS], session time zone	FOR TIME AS OF	branch
tag	tag name	@tag(name)	none
branch	branch name, main is the main chain	@branch(name)	version or timestamp

SELECT id, _distance FROM vector_search(
    "table" = "lance_catalog.db.documents", "column" = "embedding",
    "query_vector" = "[0.1, 0.2, 0.3]", "version" = "3")
ORDER BY _distance;

SELECT id, _score FROM full_text_search(
    "table" = "lance_catalog.db.documents", "column" = "content", "query" = "database",
    "branch" = "dev", "timestamp" = "2026-09-20 12:00:00")
ORDER BY _score DESC;

How it works:

• FE. The TVF parses the properties into a LanceRefSelector and loads its metadata through the same LanceCatalogClient.readTableSnapshot as table scans, so storage-versioned and namespace-managed tables follow the [feature](lance) Support time travel, tags, branches and REST Namespace managed versioning #68453 rules unchanged. Schema, search column and field id, vector type and dimension, fragments and index segments all come from the selected snapshot, and planning never reopens the dataset. The splits carry the branch directory URI and the version, so no thrift change is needed.
• Each execution resolves again. A bound TVF is never cached, prepared statements re-analyze on every EXECUTE, and TVF statements skip the SQL cache, so the latest version, a future time, a branch head and a moved tag are resolved per execution and stay fixed within its plan. CREATE TABLE AS SELECT plans its query twice (schema, then rows), so there a moving selector can resolve twice, as it already can for a table scan with an explicit selector; pinning version gives an exact copy. This is documented.
• No fallback. A snapshot that cannot be selected, or whose index files are missing, is an error; nothing falls back to the latest version.
• EXPLAIN of a search node now shows lanceCatalogType, lanceManagedVersioning and lanceBranch next to lanceVersion, as table scans do. Planner errors that name "dataset version N" also name the branch, since branch versions overlap main's.

Decisions worth calling out:

• version takes only a number. FOR VERSION AS OF 'x' names a tag because SQL has one clause for both; the TVF has a tag property, and Lance allows tag names made of digits, which FOR VERSION AS OF cannot reach.
• An empty selector value is an error rather than "not set", so an empty client-side variable cannot silently search the latest version of main.
• The selector properties must be constants. Accepting ? would leave PREPARE without a snapshot to take the result schema from. full_text_search now rejects ? in any property: until now a placeholder reached it as the literal text "?", so 'query'=? searched for "?".
• Each search relation resolves its own snapshot, as each explicit selector already does for table scans. vector_search(t) JOIN t can read two versions if a commit lands in between; pinning both with version / FOR VERSION AS OF avoids that. This is documented.
• A managed table's branch is opened by a URI Doris joins (<table>/tree/<branch>), which Lance does not validate on that path, so Doris now rejects names that could leave the table's tree/ directory or change that URI: empty segments, .., \, and ASCII characters other than letters, digits, ., -, _ and /, so ../other and a percent-encoded dot segment are rejected before the branch is opened. Outside ASCII only whitespace and control characters are rejected, so no name Lance accepts is rejected, whichever Unicode version the JDK and Lance's Rust use. Other tables check a branch out through Lance, which validates the name itself.

BE changes:

• A search split or a two-phase row fetch without a positive version is rejected instead of opening the latest version.
• Errors from opening the dataset, reading batches, preparing the FTS query context and the two-phase row fetch name the snapshot: "... at Lance dataset version N at ", with the query string and any password removed from the URI. Missing index files surface at execution because Lance loads indexes lazily.
• Fragment ids from the FE must exist in the opened snapshot. lance-c silently skips unknown fragment ids, which would drop rows without an error.
• The profile records LanceDatasetVersion and LanceDatasetUri, the snapshot an execution actually read. EXPLAIN cannot show this for moving selectors because it resolves again.
• Behavior change for every vector search: a split without index segments now always runs flat (use_index=false). The FE plans such splits as flat search, and EXPLAIN and the profile count them as flat, but Lance used to search them with the first index on the column in manifest order, which need not be the index the FE selected (for example while an index is rebuilt under a new name). Indexes the FE cannot plan with (no fragment coverage metadata, no recorded metric, or a legacy index whose details Lance cannot infer from its files, which the FE skips; lanceVectorIndexStatus=UNKNOWN_COVERAGE / METRIC_MISMATCH / NO_MATCH) are therefore no longer used implicitly, and such searches become exact flat searches. Results can change only where the unplanned index was approximate; latency can grow on such datasets. Legacy indexes that lack details but whose details Lance infers, such as those written by Lance 0.10 to 0.24, are planned and searched as before (test_lance_vector_search_legacy_index).
• A vector split that carries index segments while the request says use_index=false is rejected. The FE plans segments only when use_index allows them, so it never sends such a split; the BE now takes use_index from the segments and would otherwise have to override either the plan or the request.

Known limitations (documented):

• A branch of a branch, or a branch of a shallow clone, can fail to find the index files it inherited, because Lance writers before v13 record them under the intermediate branch (fix(dataset): keep carried index bases through chained shallow clones lance-format/lance#9176). The search fails with an error.
• After a branch is deleted and recreated under the same name, or a dataset is replaced at the same URI, version numbers repeat. Since [improvement](lance) Add ANN prefilter optimization and profiles (branch-4.1) #68615 the BE's Lance keys the index list and the row-id index by the manifest e_tag (fix(index): key metadata cache on manifest etag lance-format/lance#8904, [Enhancement][Regression-Test] enhancement for regression-test framework #8930), but the BE's process-wide Lance session still keys two entries by version alone, until eviction or restart. On datasets with stable row ids, the live-row mask that vector and full-text search prefilter with can come from the old data, so rows deleted in the new data can reappear or live rows can be missing (bug: row-address mask cache can serve a previous dataset's allow-list at the same URI lance-format/lance#9079, open). For a manifest without an e_tag (V1 naming, or a store that returns no ETag), the index list can come from the old data, on the BE and in the FE's Lance session until the catalog is refreshed. Neither is introduced by this PR.
• SHOW INDEX and lance_index_entries() keep showing the latest version of main.

Release note

vector_search() and full_text_search() accept version, timestamp, tag and branch to search a historical version, the version at a time, a tag or a branch of a Lance table, including REST Namespace managed tables. Vector search no longer uses an index the planner did not select, and full_text_search() rejects prepared-statement placeholders.

Check List (For Author)

• Test: Regression test / Unit Test
  • Regression: external_table_p0/lance/test_lance_search_snapshot (filesystem catalog) and test_lance_rest_search_snapshot (REST, storage-versioned and managed) on a new fixture search_snapshot.lance. It has seven versions (appends, a vector index, an FTS index, an append no index covers, a delete, a vector index rebuild), a tag, and a branch dev whose versions and fragment ids overlap main's with different rows, plus a tag at a non-latest branch version. search_snapshot_pruned.lance lost a version to cleanup and the index files of a tagged version. search_snapshot_evolved.lance adds a column and renames the vector column after its index is built, then appends data the index does not cover. The suites check rows, distances, two-phase reads (on a branch, a tag, the columns of a version before and after a rename, and a managed table through REST), EXPLAIN, full-text search across a delete, use_index=false with a selector, every selector error, and a managed branch named with a Unicode 16 letter (unicode_branch.lance, built by pylance 12.0.0) through a table scan, a search and a two-phase read. test_lance_rest_catalog.out and test_lance_rest_time_travel.out list the new REST tables. test_lance_vector_search_legacy_index searches a vector index written by pylance 0.18.2 without index details and checks that it is planned (USED, one segment) and returns the flat search's rows. All 30 suites in external_table_p0/lance pass locally.
  • FE unit tests: LanceSearchSelectorTest (property rules, time zones, selector forwarding), LancePreparedSearchTest (both TVFs pass their selector to the table; each analysis resolves it exactly once, and a moved tag is resolved again on the next EXECUTE; search statements bypass the SQL cache; placeholders rejected), LanceScanNodeTest (EXPLAIN, errors naming the branch), LanceCatalogClientTest (branch names, including letters newer than JDK 17's Unicode tables), and, with real datasets and locally only like the other JNI tests, LanceSearchSnapshotTest (historical index coverage, branches, tags, schema evolution, cleanup, a snapshot planned before later commits) and LanceManagedVersioningTest (managed versions, tags, branches, unfinalized heads through the search entry points).
  • BE unit tests in lance_reader_test.cpp: missing fragment ids on normal, vector and FTS splits, unpinned versions, error and profile contents, a split without index segments searching flat although an index covers it, and a split with index segments under use_index=false being rejected. The indexed variants of the existing multi-vector tests now pass the index segments the FE would plan.
• Behavior changed: Yes. New TVF properties; vector splits without index segments always search flat; full_text_search rejects ?; managed branch names are validated; the error for a time in removed history now reads "Lance cannot select the version at or before '...'" instead of "Lance cannot resolve FOR TIME AS OF '...'", because the TVF reaches it too; BE errors name the dataset version and URI.
• Does this need documentation: Yes ([docs](lance) Search historical versions, tags and branches with the search functions doris-website#4185)

[hello-stephen]

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:

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

[zy-kkk]

run buildall

[zy-kkk]

/review

[github-actions]

Review status: COMPLETE for head ebe7d6f. Static review covered all 99 changed paths, the prepared diff, regression expectations, and the relevant FE/BE call chains. One P2 test-coverage finding is inline. The prepared threads and live PR comments contain no existing P0/P1 finding to carry. No additional user focus was supplied.

Critical checkpoints:

• Goal and scope: Snapshot-aware Lance vector and FTS search is wired from TVF selector parsing through catalog metadata, FE split planning, BE scan, and row-id fetch. The change is focused on this feature and its fixtures/tests; the active regression proof for historical branch selectors is incomplete as noted inline.
• Correctness and conditionals: Reviewed conflicting/invalid selectors, missing versions, strict versus index-only FTS coverage, mixed indexed/flat vector splits, historical deletes, schema evolution, and fixed positive versions. The same selected URI/version flows to search and two-phase fetch; no additional concrete wrong-row path survived review.
• Concurrency and lifecycle: Per-query metadata pins URI/version across planning and BE reads, including when a tag or branch head later moves. Reader close/reopen resets snapshot-related state; no new lock ordering or shared mutable state was found. Resource and allocator lifetimes were traced across metadata reads and scans.
• Configuration and compatibility: No new dynamic configuration or Doris transaction/EditLog path is introduced. FE/BE reuse the existing scan transport for URI, version, fragments, and index segments. Filesystem and managed REST catalogs, main/branch/tag selection, and vector/FTS paths were checked separately; rolling-upgrade behavior was assessed statically only.
• Parallel paths and observability: Reviewed normal scans, search scans, prepared TVFs, and lazy row fetch, plus branch/tag and managed table resolution. Existing errors, EXPLAIN fields, and metadata/scan profiling expose the selected version and coverage; no separate observability defect was substantiated.
• Tests and results: Inspected FE/BE unit tests, SQL regressions and expected output, binary fixture inventory, and compose/REST setup. The new JNI snapshot test class is disabled; active tests leave the historical branch selector gap described inline. Builds and tests were prohibited and were not run, so no runtime result is claimed.
• Performance and writes: The fixture builder stages and promotes test data; this PR does not add a Doris data-write or persistence path. Vector indexes without usable segment details now take flat search, which can be costly for older large datasets; available metadata did not establish a safe indexed fallback, so this remains a review limitation rather than a separate inline finding.

[github-actions]

[P2] Exercise a historical snapshot on the dev branch. This branch=dev,version=4 query selects the fork point, whose rows and indexes match main version 4, so a second checkout on main in readFromLatest would still pass. The branch timestamp assertion asks for year 2999, so ignoring that timestamp also selects dev head. Add discriminating assertions: explicit dev version 6 with STRICT FTS (dev rebuilt coverage over fragment 2, main v6 did not), and an as-of time between dev commits 5 and 6 with lanceVersion=5. The JNI snapshot test class is disabled, leaving these search paths without an active historical check.

[zy-kkk]

Agreed: the fork-point version and the future timestamp could not tell the branch from main, or the time from the head. Added in e55bd49:

• branch=dev, version=5 returns the branch's rows 101/102/103 (main version 5 would return 24/23/22), with EXPLAIN lanceVersion=5 and lanceBranch=dev.
• STRICT full_text_search succeeds on branch=dev, version=6, whose body_idx was rebuilt over fragment 2, and fails on main version 6.
• branch=dev, timestamp=2026-09-29 14:52:18, between dev versions 5 and 6, gives EXPLAIN lanceVersion=5, and STRICT full-text search fails naming dataset version 5 of branch 'dev'. Ignoring the time would select dev version 6, and resolving it on main would select main version 7.

All 29 suites in external_table_p0/lance pass locally.

[zy-kkk]

run buildall

[zy-kkk]

/review

[github-actions]

Review complete at head e55bd497a453399971f3ae57d5b993261eedd006 after two convergence rounds and a final sweep of all 99 changed paths. Two distinct inline findings follow: a P2 legacy vector-index performance regression and a P3 historical two-phase test gap. No P0/P1 finding was substantiated.

Critical checkpoints

• Goal and scope: The search TVFs now select version, timestamp, tag, and branch snapshots; FE binds schema/index metadata from the selected snapshot and sends its URI and positive version through existing split fields. The production changes are focused on that path and its BE checks.
• Concurrency and lifecycle: No new threads or locks were added. The BE fragment list is reader-local, bound to the opened dataset key, and reset on close; a changed URI/version/options key fails. Search and row-id fetch reject an unpinned version, and missing fragment IDs fail rather than silently dropping rows. No new cross-translation-unit initializer or ownership cycle was found.
• Compatibility and parallel paths: Reviewed filesystem and managed REST resolution, main and dev histories, vector indexed/flat/disabled paths, FTS coverage, normal scans, prepared re-execution, SQL cache exclusion, and two-phase row fetch. Existing Thrift URI/version/options fields carry the selection. The compatible legacy-index path has the P2 regression reported inline; no other mixed-path defect was substantiated.
• Conditions, persistence, and writes: Selector combinations, timestamp parsing in the session time zone, branch-name validation, and deleted/pruned histories have explicit errors or conservative fallback. Production changes do not add configuration, transaction writes, or persistent Doris metadata. The fixture generator writes test datasets only.
• Tests and observability: Inspected FE/BE tests, generated regression outputs, fixture histories, and active filesystem/REST suites, including negative and schema-evolution cases. The JNI snapshot test class is disabled; active assertions cover its main historical paths, with the P3 two-phase gap noted inline. EXPLAIN shows the selected version/branch, and BE profile/errors identify the opened snapshot. No builds or tests were run in this review, as instructed; the author's local test claim was not treated as independent validation.
• Performance and remaining questions: The P2 flat-scan regression is the remaining performance concern. All other main risk items and candidate points have a recorded conclusion; no unresolved suspicious point remains.

Existing inline discussion 4172612906 is a P2 test concern already addressed on this head by discriminating dev version-5 rows, dev version-6 STRICT FTS, and a between-commit timestamp. It is not reposted or carried as a P0/P1 blocker. No additional user review focus was supplied.

[github-actions]

[P2] Preserve ANN use for compatible legacy indexes. A dataset with one legacy L2 vector index whose physical entries have no index details is skipped by describeUserIndexes; FE then sends fragment splits without a segment UUID, so this line overrides even use_index=true and scans every vector flat. Previously Lance could select that index for the same query, so large existing collections lose indexed-search performance. Recover enough metadata to plan a compatible legacy index or provide another safe indexed path, and add a legacy-index execution regression.

[zy-kkk]

I checked this against real legacy indexes before changing anything. Indexes without index details written by pylance 0.10.18 and 0.18.2 (IVF_PQ, L2) and 0.24.1 (IVF_PQ, cosine, multi-vector) are not skipped: Lance infers the missing details from the index files when it loads the index (infer_missing_vector_details), so describeUserIndexes describes them, the FE plans one segment (lanceVectorIndexStatus=USED), and the BE profile shows LanceIVFPartitionsSearched: 1 with no flat-search fragments.

The skip in describeUserIndexes is now reached only when that inference fails, for example when an index file cannot be read at planning time. Doris then cannot verify the index's coverage or metric, so a flat search is the conservative result, and a persistent failure would break the BE's use of the index too.

Added in a7b9979: legacy_vector_index.lance, built by pylance 0.18.2 without index details, and test_lance_vector_search_legacy_index, which checks that the index is planned with one segment and that the indexed search returns the flat search's rows. The docs now say an older index is skipped only when Lance cannot infer its details.

[github-actions]

[P3] Make this historical tag test exercise and distinguish phase-two fetch. rel selects version 5, but rows 24/23/22 and their body values are identical at latest version 7; this result would still pass if row-id fetch reopened v7. This query also lacks the adjacent VMaterializeNode EXPLAIN assertion. Assert that plan shape and select historical payload that changes or disappears in a later version (for example, row 3, deleted in v6) so the test proves the fetched rows came from the selected snapshot.

[zy-kkk]

Done in a7b9979: the tag case now searches next to row 3, which rel (version 5) still has and version 6 deleted. A fetch from a later version would return fewer rows and fail the row-count check. It also asserts VMaterializeNode.

[zy-kkk]

run buildall

[zy-kkk]

/review

[github-actions]

Complete static review of PR #68707 at a7b9979. No new actionable inline findings. The user supplied no additional focus points.

The change enables vector_search() and full_text_search() to select a Lance version, timestamp, tag, or branch. FE derives schema, field IDs, fragments, and indexes from one selected Dataset, then sends its URI and positive version in each split. BE uses that fixed snapshot for search and row-id fetch, validates FE fragment IDs against the opened dataset, and follows FE's segment plan for indexed versus flat vector splits. I inspected the active filesystem and REST regression cases, BE and FE unit tests, fixture generators and committed history, and expected outputs. The JNI LanceSearchSnapshotTest class is disabled, so the active regression suites are the relevant end-to-end coverage. Builds and tests were prohibited and were not run; author-reported passing suites are not independent validation here.

Previously reported inline concerns: #4172612906 [P2] is addressed by active dev-v5 rows, dev-v6 STRICT FTS, and an intervening dev timestamp assertion; #4172821003 [P3] is addressed by the VMaterializeNode assertion and a tagged row deleted in a later version; #4172821000 [P2] remains the existing legacy-index discussion, with an inferable legacy fixture and index-planning regression added on this head. I did not repost these threads. No existing P0/P1 inline finding was independently confirmed as still applicable.

Critical checkpoints:

• Goal and tests: historical selectors are propagated through metadata, split planning, BE scanning, and phase-two fetch. Active SQL cases cover main and dev with equal numeric versions, tags, timestamps, index coverage, deletes, missing versions, schema evolution, and row fetch. This is inspected coverage, not an executed result.
• Scope and clarity: production edits are confined to Lance search/snapshot handling and the related prepared-statement parser check. Added binary fixtures support version, branch, pruning, evolution, and legacy-index scenarios.
• Concurrency and locks: metadata is resolved per read and the BE fragment-ID cache is reader-owned; split reuse is sequential for that reader. No new thread entry, shared lock, nested-lock order, or heavy operation under a new lock was introduced.
• Lifecycle and initialization: opened URI/version/options remain fixed for reader reuse; scanner and FTS context cleanup and fragment-cache reset were traced. No new cross-translation-unit static initializer dependency was found.
• Configuration: no product configuration item was added, so dynamic-change handling is inapplicable. Regression suites restore their session settings.
• Compatibility: selector omission retains latest-main behavior. Existing Thrift version and index-segment fields carry the selected snapshot; no new storage format or transmitted variable was introduced. Legacy-index and older-BE behavior was checked against the existing inline discussion; no distinct regression on this head was substantiated.
• Parallel paths and conditions: normal scan, vector search, FTS, and take_rows were traced. Positive search/fetch versions, fragment membership, and contradictory use_index/index-segment checks fail explicitly; indexed and uncovered vector splits take their intended paths.
• Test results and negative cases: active suites and expected .out files include missing selector targets, invalid combinations, pruned history, managed namespace gaps, branch differences, and lazy materialization. No test result was generated or verified by running it in this review.
• Observability: BE profiles now name the opened version and sanitized URI, and errors name the snapshot; existing index and flat-search counters remain available.
• Transactions, persistence, and writes: production changes are external read paths, with no Doris transaction, EditLog, or product data-write change. Fixture construction stages and checks histories before catalog promotion; that construction was inspected only.
• Performance and other issues: BE caches the fragment list for an opened reader and uses FE segment selection to avoid unintended ANN work on flat splits. No further substantiated performance or correctness issue survived the final sweep.

All 109 changed paths in the authoritative diff were covered. Three normal and two risk-focused subagent passes returned NO_NEW_VALUABLE_FINDINGS. One final-sweep mixed-version hypothesis was checked and dismissed as a pre-existing legacy-index behavior at an already-commented location without a distinct verified failure on this head. No candidate remains unresolved. Review complete.

[hello-stephen]

BE UT Coverage Report

Increment line coverage 77.32% (75/97) 🎉

Increment coverage report
Complete coverage report

Category	Coverage
Function Coverage	61.18% (26788/43785)
Line Coverage	45.82% (278347/607511)
Region Coverage	41.53% (220629/531268)
Branch Coverage	43.00% (102250/237788)

[hello-stephen]

FE UT Coverage Report

Increment line coverage 83.02% (88/106) 🎉
Increment coverage report
Complete coverage report

[hello-stephen]

BE Regression && UT Coverage Report

Increment line coverage 77.32% (75/97) 🎉

Increment coverage report
Complete coverage report

Category	Coverage
Function Coverage	74.92% (31900/42580)
Line Coverage	59.25% (357024/602615)
Region Coverage	55.92% (297729/532402)
Branch Coverage	56.79% (134886/237505)

[hello-stephen]

FE Regression Coverage Report

Increment line coverage 71.70% (76/106) 🎉
Increment coverage report
Complete coverage report

[Gabriel39]

Reviewed commit a7b99799c5235919fece14d978bae065b5a945bd.

Review conclusion: request changes — one managed-branch compatibility regression.

The new isLanceAlphanumeric check uses JDK 17 character classifications, which use Unicode 13. The pinned Lance 12.0.0 validates names with Rust is_alphanumeric; its minimum Rust version is 1.91, whose tables use Unicode 16. These predicates therefore accept different sets of characters.

For example, devᲉ contains U+1C89 (CYRILLIC CAPITAL LETTER TJE), introduced in Unicode 16. A Lance-created managed branch with this name and a valid namespace-recorded version is accepted by Lance but rejected by the new Java guard with Invalid Lance branch name.

This also breaks the existing ordinary managed-table query path, not just the new search TVFs:

SELECT * FROM catalog.db.items@branch('name'='devᲉ');

At the merge base, readManagedBranch opened the recorded version without this Java character filter. At this head, validation rejects the name before namespace lookup. This is a narrow functional compatibility regression (Major under the review rubric); no data corruption or resource-exhaustion claim is intended.

Suggested fix: retain the traversal and unsafe-URI checks, but align character acceptance with the pinned Lance contract, through native validation or matching versioned Unicode data. Add coverage for an existing managed branch containing a post-Unicode-13 letter, for both ordinary scans and search TVFs.

References: JDK 17 Character, Lance v12 branch validation, Lance v12 Rust requirement, Rust 1.91 Unicode tables.

Validation scope: two static review rounds covering all 109 changed files and relevant dependency contracts. No builds, tests, or JNI reproduction were run. No additional substantiated blocking findings were identified.

[zy-kkk]

Thanks, confirmed: a managed branch named devᲉ was rejected by the guard, including @branch(...) table scans. Fixed in 0eac821.

I did not align the guard with Lance's character set exactly, because neither route stays aligned:

• Native validation: the Lance 12 Java SDK exposes no branch-name validator. check_valid_branch only runs inside Rust (checkout_by_ref and the dataset builder), and the managed path opens the joined URI without it.
• Versioned Unicode data: the tables Lance uses come from the rustc that built the shipped lance-jni and lance-c, not from the minimum Rust version, so FE and BE can differ, and a table copied into Java would drift again on the next toolchain bump.

So the guard no longer decides whether a name is valid. It only keeps the joined URI inside the table's tree/ directory:

• Rejected: empty, a leading or trailing /, empty segments, .., a trailing .lock, \, and any ASCII character other than letters, digits, ., -, _ and /. In ASCII this is exactly Lance's set, and no segment can climb out of tree/, percent-encoded or not.
• Outside ASCII only whitespace and control characters are rejected. ASCII classification does not depend on the Unicode version, and no whitespace or control character has ever been alphabetic or numeric, so every name check_valid_branch accepts passes, whichever Unicode version the JDK or rustc uses.
• A name that passes but that Lance would reject cannot have been created by Lance, so the namespace reports it as a branch it does not record.

Coverage, as you suggested, on an existing managed branch with a post-Unicode-13 letter:

• unicode_branch.lance has a branch devᲉ (U+1C89, Unicode 16), served by the REST fixture as the managed table unicode_branch_managed. It is built with pylance 12.0.0, since Lance 7 stores a non-ASCII branch directory percent-encoded, which Lance 12 does not find.
• test_lance_rest_search_snapshot reads that branch through an @branch table scan, vector_search(... "branch"="devᲉ") and a two-phase read.
• LanceCatalogClientTest checks that devᲉ and other non-ASCII letters and digits are accepted, and that the unsafe names are still rejected.

[zy-kkk]

run buildall

[hello-stephen]

BE UT Coverage Report

Increment line coverage 84.54% (82/97) 🎉

Increment coverage report
Complete coverage report

Category	Coverage
Function Coverage	61.18% (26787/43785)
Line Coverage	45.82% (278345/607511)
Region Coverage	41.52% (220567/531268)
Branch Coverage	43.00% (102250/237788)

[hello-stephen]

FE UT Coverage Report

Increment line coverage 80.95% (85/105) 🎉
Increment coverage report
Complete coverage report

[hello-stephen]

BE Regression && UT Coverage Report

Increment line coverage 84.54% (82/97) 🎉

Increment coverage report
Complete coverage report

Category	Coverage
Function Coverage	74.91% (31895/42580)
Line Coverage	59.22% (356876/602615)
Region Coverage	55.86% (297422/532402)
Branch Coverage	56.76% (134813/237505)

[hello-stephen]

FE Regression Coverage Report

Increment line coverage 72.38% (76/105) 🎉
Increment coverage report
Complete coverage report

[zy-kkk]

/review

[github-actions]

Complete static review of PR #68707 at head 0eac821. No new actionable findings. All three Round 1 review passes returned NO_NEW_VALUABLE_FINDINGS; the final changed-file and unresolved-point sweep found none. There was no additional user-provided focus.

Critical checkpoints:

• Goal and evidence: Both Lance search TVFs accept version, timestamp, tag, and branch selectors. The selected URI and positive version flow from catalog metadata into FE splits, BE search, and phase-two row-id fetch. Active external regression suites inspect distinct main/branch rows, historical deletion, index coverage, schema evolution, managed namespace gaps, and lazy materialization. The new LanceSearchSnapshotTest class is disabled by its stated JNI ABI limitation, so its assertions are not executed coverage.
• Scope and parallel paths: Changes stay within selector plumbing, snapshot diagnostics, BE plan enforcement, and fixtures. Vector and full-text searches, indexed and basic metadata loading, managed and filesystem catalogs, and table scans share the relevant resolver behavior. Invalid combinations and unavailable snapshots fail explicitly.
• Concurrency and lifecycle: No new threads, locks, or shared mutable state were added. One catalog client lease reads a selected Dataset snapshot; the metadata retains its URI/version after the handle closes. A BE reader retains one dataset key for its splits; its fragment-ID cache resets on close. No new static initialization dependency was found.
• Configuration and compatibility: No configuration item or Thrift field was added. Existing URI/version fields carry selectors across FE and BE, and the smooth-upgrade check for additional reader types remains in place. The older BE's optional automatic index choice for segmentless splits predates this PR; no distinct new selector-specific wrong-result path was substantiated.
• Conditional checks, data correctness, and performance: BE rejects unpinned search/fetch versions and fragments absent from the opened snapshot. Indexed vector splits use FE-selected segment UUIDs; uncovered splits search flat. FTS retains strict/index-only coverage behavior. The extra fragment listing is once per opened BE dataset, not per batch. No reachable new correctness, memory, or performance defect was substantiated.
• Tests and results: I inspected FE and BE unit cases, fixture builders/artifacts, regression SQL, and expected output; I did not run builds or tests, as required by the review prompt. The author-reported local suite results are not independent validation. Negative cases cover invalid selectors, missing versions/tags/branches, prepared placeholders, timestamp zones, and missing fragment IDs.
• Observability, persistence, and writes: EXPLAIN now names catalog type, version, managed status, and branch; BE errors/profile identify the opened snapshot. FE changes add no EditLog, transaction, or data-write operation. No new FE-to-BE variable requires separate sending paths.

Existing inline P2/P3 threads on historical branch assertions (4172612906), legacy ANN planning (4172821000), and historical tag phase-two coverage (4172821003) were read and checked against the current diff. Their current-head follow-ups add discriminating assertions/fixtures; I found no distinct new issue to repost. No existing P0/P1 inline finding remains to carry.

[Gabriel39]

The updated managed-branch guard addresses the Unicode compatibility issue from my earlier review: it checks URI/path safety without relying on the JDK to recognize every character accepted by Lance. The added coverage includes the existing managed branch scan and search paths. Approved based on static review; tests were not run locally.

[hello-stephen]

BE Regression && UT Coverage Report

Increment line coverage 84.54% (82/97) 🎉

Increment coverage report
Complete coverage report

Category	Coverage
Function Coverage	74.92% (31936/42628)
Line Coverage	59.27% (357695/603550)
Region Coverage	55.95% (298191/532927)
Branch Coverage	56.83% (135219/237916)

[hello-stephen]

FE Regression Coverage Report

Increment line coverage 55.07% (76/138) 🎉
Increment coverage report
Complete coverage report