fix(mem-wal): resolve writer shard spec identity - #8112
Conversation
a82f42f to
9c6f90d
Compare
|
Important This PR touches the Lance format specification. Substantive changes to the format specification — the If this is a meaningful format change:
|
There was a problem hiding this comment.
Gate recommendation: maintainer decision required.
The fresh-shard writer fix is sound, but the PMC must choose whether the format should make activity implicit in the maximum append-only ID (simple, but commits future cutover and rollback semantics) or persist an explicit active ID (more metadata, but independent activation). This substantive format change requires the documented three binding +1 votes and one-week period; no completed vote is linked. Please link that vote before accepting the contract.
9c6f90d to
dbb9b85
Compare
There was a problem hiding this comment.
Gate recommendation: maintainer decision required.
The fresh-shard writer fix is sound, but the PMC must choose whether the format should make activity implicit in the maximum append-only ID (simple, but commits future cutover and rollback semantics) or persist an explicit active ID (more metadata, but independent activation). This substantive format change requires the documented three binding +1 votes and one-week period; no completed vote is linked. Please link that vote before accepting the contract.
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
0c3ae83 to
369c3ae
Compare
Summary
shard_spec_id(0) to the MemWAL index's sole automatic sharding spec before creating or claiming a shard manifest0Dataset::mem_wal_writerboundary plus invalid manual, mismatched, and multiple-spec inputsScope
This PR fixes the current writer path only. MemWAL initialization already creates either no spec (manual sharding) or one automatic spec with id
1; the writer must record that same identity instead of its unresolved default0.It does not add monotonic allocation, spec revisions, activation semantics, metadata validation for hypothetical producers, or a file-format change. Those require a separate end-to-end design if a re-shard API is introduced.
This PR complements but is not a prerequisite for #7949: this PR resolves the table identity before a fresh manifest is created, while #7949 defensively rejects changing an identity already stored in a manifest.
Testing
cargo fmt --all -- --checkcargo test -p lance --lib test_writer_shard_spec_resolution_rejects_invalid_identity -- --nocapturecargo test -p lance --lib test_mem_wal_writer_uses_automatic_sharding_spec -- --nocapturecargo clippy --all --tests --benches -- -D warnings