Skip to content

Tracking: feat/disk-offload follow-up roadmap (P0-6 → P2-5) #55

Description

@TinDang97

Umbrella tracking issue for the 11 follow-ups filed after the senior-Rust review of #43. Groups them into execution waves so contributors can pick work without blocking each other.

Source plan: `.claude/plans/dreamy-whistling-haven.md` (local). The original P0 batch already shipped in #43 commit `a50eead`.

Dependency map

graph LR
  subgraph W1["Wave 1 — isolated, parallelizable"]
    I44["#44 P0-6 ext: bounded LZ4 (kv_page ×2, warm_search)"]
    I49["#49 P1-6: DiskANN io error propagation"]
    I46["#46 P1-3: streaming cold-tier decode"]
    I53["#53 P2-4: format_version headers"]
    I47["#47 P1-4: ShardManifest borrow audit"]
  end

  subgraph W2["Wave 2 — structural"]
    I51["#51 P2-2: break manifest cycle"]
    I45["#45 P1-2: precompute shard_dir"]
    I48["#48 P1-5: manifest MAX_INLINE_ENTRIES cap"]
  end

  subgraph W3["Wave 3 — recovery hardening"]
    I52["#52 P2-3: index manifest in recovery"]
    I54["#54 P2-5: recovery test coverage gaps"]
  end

  subgraph W4["Wave 4 — global cross-cut"]
    I50["#50 P2-1: Cargo feature gate disk-offload"]
  end

  I47 --> I51
  I51 --> I48
  I51 --> I52
  I52 --> I54
  I45 --> I50
  I51 --> I50
  I44 --> I50
  I46 --> I50
  I49 --> I50
  I53 --> I50
  I48 --> I50
  I54 --> I50
Loading

Wave 1 — isolated fixes (start here in parallel)

These are surgical, single-module, no dependencies on each other. Five different contributors can take them simultaneously.

# Title Files Effort
#44 Extend bounded LZ4 helper to non-FPI sites `persistence/kv_page.rs` (×2), `vector/persistence/warm_search.rs` S
#49 DiskANN `uring_search` error propagation `vector/diskann/{uring_search,segment}.rs` M
#46 Streaming cold-tier vector decode `storage/tiered/cold_tier.rs` M
#53 `format_version` headers (KvLeafPage + DiskANN) `persistence/kv_page.rs`, `vector/diskann/{segment,pq,vamana}.rs` S
#47 ShardManifest borrow audit read-only investigation (no edits) S

Why first: zero coupling, zero risk to other in-flight work, individually mergeable. #47 is investigation-only and feeds Wave 2.

Wave 2 — structural (after Wave 1, depends on #47)

Module-shape changes that touch many files. Need #47's borrow audit to land first so we know whether `ShardManifest` needs to become `RefCell`-wrapped before the structural cleanup.

# Title Depends on Effort
#51 Break manifest ↔ cold_index ↔ cold_tier circular dep #47 M
#45 Precompute per-shard disk-offload paths — (parallel with #51) M
#48 ShardManifest `MAX_INLINE_ENTRIES` warning + metric #51 S (warning only; real overflow-pages fix is its own phase)

Why second: #51 unblocks clean module boundaries. #45 is independent but should land before #50 (feature gate) to avoid reworking the cfg decoration. #48 needs the new module shape from #51.

Wave 3 — recovery hardening (after Wave 2)

# Title Depends on Effort
#52 Index manifest entries once in recovery (O(files × phases) → O(files)) #51 M
#54 Recovery test coverage gaps #52 M

Why third: #52 changes recovery internals; #54's new tests target that code so they should be authored after the refactor.

Wave 4 — global cross-cut (last)

# Title Depends on Effort
#50 Cargo feature gate `disk-offload` every wave L

Why last: `#[cfg(feature = "disk-offload")]` will need to decorate every file the previous waves touched. Doing this last means the gating PR is purely additive (`cfg` annotations + `Cargo.toml`) and does not conflict with any in-flight work. Once it lands, the tokio CI matrix will verify the gates compile cleanly.

Suggested branch / PR layout

Out of scope for this roadmap

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions