feat: send read-freshness signal on the lance-namespace path#3551
Merged
Conversation
There was a problem hiding this comment.
Claude Code Review
This repository is configured for manual code reviews. Comment @claude review to trigger a review and subscribe this PR to future pushes, or @claude review once for a one-time review.
Tip: disable this comment in your organization's Code Review settings.
rpgreen
approved these changes
Jun 17, 2026
|
Docs PR opened: lancedb/docs#276 Clarified that read_consistency_interval applies to all db:// remote tables and updated the read-your-write description to match current client behavior. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
db://-style connections that use the lance-namespace path (LanceNamespaceDatabase→NativeTable+ the lance-namespace REST client) never sent a read-freshness signal. Against a server configured to serve cached table metadata up to some staleness window, this allows stale-read-after-write across handles and processes. The remote table path already solved this (#3439). This brings the namespace path to parity.The namespace REST client doesn't let callers attach headers directly, but it forwards a
DynamicContextProvider'sheaders.*context entries as HTTP headers per request. So:ConnectBuildervia a context provider.(RFC3339), keyed by the operation'sobject_id`.checkout_latest(),restore(), and every data/schema write.checkout_latest()is the primary hook: consumers refresh a handle there after writing elsewhere, then poll.Read operations that carry the floor:
describe_table,list_table_versions,query_table,list_tables.list_table_versionsis what resolves "latest" for managed-versioning tables (get_latest_version), so it's the op that makescheckout_latest()actually observe a prior write.describe_table_versionis excluded (pinned to an immutable version). This mirrors #3439 (timestamp baseline,max(baseline, now − interval), monotonic); nomin_versionand no body channel, since the namespace path has no version-returning write responses.Testing
compute_min_timestamp/next_freshness_baselineand the provider (header at/after a bumped baseline; nothing for an empty baseline + no interval; interval floor applies; non-read ops emit nothing;list_tablesuses only the interval floor).x-lancedb-min-timestamp, writes don't, and read-your-write holds.