Skip to content

feat: run owned WAL catch-up inside native masters - #390

Merged
beinan merged 5 commits into
mainfrom
codex/master-native-recovery
Oct 19, 2026
Merged

beinan merged 5 commits into
mainfrom
codex/master-native-recovery

Conversation

@beinan

@beinan beinan commented Oct 19, 2026 •

Copy link
Copy Markdown
Collaborator

Owned generic/upsert tables currently need worker fan-out or a dedicated catch-up process even when resident master capacity is available. Add MASTER_LOCAL_MERGE_TARGETS so native masters claim these tables from the existing durable queue and run bounded WAL catch-up themselves; additional master replicas can service different tables.

The resident path reuses the existing ordered catch-up implementation, maintenance progress watchdog and storage fencing, while sharing one buffer budget per master. Both generic and ordinary rollout tables gain metadata-only demand discovery and durable continuation after bounded passes. Existing append-only preparation remains available. * selects explicitly owned, non-draining targets only; this does not migrate legacy ownership or import external recovery ledgers, and requires no new Kubernetes pool or RBAC.

Validation: local master unit suite passed (102 tests); real-etcd resident suite passed (10 tests), including generic upserts over a 16-pass boundary, successor claims on another master, concurrent ingestion, independent table execution under a saturated per-master budget, external-owner exclusion and reserved capacity during legacy RPC saturation. The existing dedicated-executor regression also passed with 1/2/3 MiB shared budgets (1 test, three configurations). The final drain fix allows resident-only masters with no worker endpoints to reconcile previously recorded executions while draining. On head f4c28e1, the 102 master unit tests, 13 resident tests (including 10 real-etcd tests), and targeted no-worker drain integration test passed. The dedicated executor regression was also rerun successfully on f4c28e1; 16 legacy supervisor tests also passed. Formatting and diff checks passed. Full CI remains in progress.

Deployment requires a mixed-version staging check and a qualified ownership handoff. This change does not retire existing external consumers by itself.

@beinan
beinan marked this pull request as ready for review October 19, 2026 17:51
@beinan
beinan merged commit 57f4cdb into main Oct 19, 2026
11 checks passed
beinan added a commit that referenced this pull request Oct 19, 2026
Production recorded `/records` reads taking 217–241 seconds before
returning 404. The recovery endpoint retained only 5xx outcomes, while
route-level latency histograms could not identify the affected table.

Retain the latest completed read taking at least five seconds in the
existing bounded per-table hint cache, including its status and
response-header duration. These additive schema-1 fields preserve the
nonblocking recording path, five-minute expiry, 4,096-entry cap and 1
MiB response limit. Failures and slow reads precede ordinary activity
when the response is truncated. Request parameters, record IDs and
payloads are excluded. This supplies diagnostic hints; it does not
cancel requests or infer that a slow read needs a merge.

Validation: metrics unit tests passed (10, plus one ignored manual
benchmark); enabled/disabled HTTP integration tests passed, including a
delayed 404, in-flight demand and payload exclusion. Tests also cover
threshold boundaries, independent expiry, preservation after successful
requests, lock contention and bounded truncation. `cargo clippy -p
lance-context-metrics --all-targets -- -D warnings`, formatting and diff
checks passed. This is independent of #390 and does not block its
release.

Co-authored-by: Beinan Wang <beinanwang@microsoft.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant