db-09 — Verification

How to reproduce the green status on a clean machine.

Prerequisites

  • macOS or Linux with Apple Clang / clang ≥ 14 / gcc ≥ 11.
  • cmake ≥ 3.20.
  • Rust toolchain ≥ 1.74 (rustup default stable).
  • Go ≥ 1.22.
  • shasum, xxd, awk (default on macOS; coreutils on Linux).

One command

cd db-09-leveldb-complete
scripts/verify.sh        # builds + unit tests in all three langs
scripts/cross_test.sh    # cross-language sha256 match

Both should print === OK === / === ALL OK === and exit 0.

Per-language drill-down

Rust

cd db-09-leveldb-complete/src/rust
cargo test --quiet
cargo build --release

Expected: 11 passed; 0 failed. The dbctl binary lands in target/release/dbctl.

Go

cd db-09-leveldb-complete/src/go
go test ./...
go build ./cmd/dbctl

Expected: ok github.com/10xdev/dse/db09 <duration>.

C++

cd db-09-leveldb-complete/src/cpp
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build -j
ctest --test-dir build --output-on-failure

Expected: 100% tests passed, 0 tests failed out of 1 and the test_db09 binary prints OK.

What "green" means

A green run guarantees:

  • All 33+ unit tests pass (11 each in Rust, Go, C++).
  • The cross-language test produces byte-identical DUMP and DUMP_WITH_TOMBS after a close/reopen cycle.
  • Spot-checked hex bytes for b=222, e=5, and the tombstone for a are present in the stream — guarding against accidental empty-output regressions.

When verification fails

  • Cross-language sha256 mismatch — almost always a divergence in one of: WriteBatch wire format, MANIFEST line format, SST writer ordering, MergingIterator tie-break, or whether tombstones are dropped. The fix is almost never in db-09; it's in the upstream lab whose format drifted.
  • Recovery test fails in one language only — that language's WAL truncation step is wrong. Pattern (all three use it): close WAL → remove file → reopen WAL.
  • C++ ctest reports zero tests — you accidentally did add_subdirectory(../db-NN). Compile upstream .cc directly instead.