feat(vector): fuse the BBQ rerank distance kernels

[EnRaiha]

Supersedes #351. That branch lives upstream in this repo and this account has no push access to it, so this is the fork-based PR instead. The single commit carries the fused-kernel change plus every point from both reviews.

Rebased onto f18b31edf — 65 commits, which moved nodedb-vector by 64 files (+3958/−1522). No conflicts; the only overlapping files were Cargo.lock and hnsw/graph/index/state.rs, both resolved cleanly.

Why

Rerank against 1-bit BBQ candidates materialized a Vec<f32> per candidate (and per query). At an oversample × ef candidate count that dominated the pass and defeated SIMD. This is the fused-kernel work of #280.

What

• the kernels read the centered query straight from the prepared payload bytes: zero allocation per candidate and per query
• the kernels join the dispatch table that already exists: l2_bbq is a SimdRuntime field in distance/simd/runtime.rs, selected in SimdRuntime::detect() beside l2_squared_f16 / l2_squared_bf16. Order: avx512 → avx2+fma → neon → wasm-simd128 (wasm32 + simd128 only) → scalar
• every safe entry point validates both byte slices against dim before any pointer arithmetic. Reading the centered query out of raw payload bytes means a short slice would otherwise be a read past the end, and dispatch guarantees the host's features, never the shape of the data. One shared guard, bbq::assert_payload_shapes, is called by the scalar kernel and all four tiers; saturating_mul keeps dim * 4 from wrapping past the check
• simd::avx2 and simd::avx512 are pub(crate). Their entry points are safe pub fns calling #[target_feature] implementations, so exposing the modules let safe code outside the crate execute AVX2 or AVX-512 on a host without it. SimdRuntime::detect() is the only supported way to reach a tier; neon and wasm_simd128 stay public, being baseline and compile-time gated respectively
• distance_prepared rejects a candidate whose header names another dimension or quantizer rather than scoring it, and the prepared-payload length uses checked arithmetic. A buffer long enough to parse is not proof it belongs to this codec
• fluxbench is a non-wasm dev-dependency. It pulls tokio, which does not build for wasm32, so the crate's wasm unit tests could not be built at all — and this PR moves the wasm f32 kernels from scalar to SIMD, which would have left them unverified
• the wasm f32 kernels are now dispatched, not just compiled: wasm_simd128 was undeclared on main, and this PR declares the module and adds the detect() arm, gated on the same compile-time condition as the tier module
• the NEON arm is gated to little-endian aarch64 (it reinterprets the little-endian payload), and its loads go through vld1q_u8 + vreinterpretq_f32_u8 so they do not depend on 4-byte alignment
• decode_payload / the old dequantize path are removed
• one commit, rebuilt rather than appended to

Validation

Run under cargo nextest, which is what this repo requires.

Check	Result
cargo nextest run -p nodedb-vector --all-features --cargo-profile ci --profile ci	511 passed, 0 failed
cargo nextest run --workspace --exclude nodedb-cluster-tests --all-features --cargo-profile ci --profile ci	17,897 passed, 0 failed, 0 skipped
wasm lib suite, wasm32-wasip1 +simd128, under Node's WASI runner	374 passed, 0 failed
cargo check --workspace --all-features --profile ci	clean
cargo fmt --all --check	clean
cargo clippy --workspace --all-targets --all-features --profile ci -- -D warnings (stable 1.98.1)	clean
nodedb-preflight.sh <repo> origin/main	pass
cargo check -p nodedb-vector --target aarch64-unknown-linux-gnu	clean
cargo check -p nodedb-vector --target wasm32-wasip1 with and without +simd128	clean both ways

The guard and the seam are pinned by tests checked by mutation, not by green alone: deleting the guard from avx2::l2_bbq makes simd_length_safety::bbq_rejects_short_slices die with SIGSEGV — the original blocker reproducing itself — and shifting the seam to &payload[0..] makes distance_prepared_matches_the_unfused_l2 fail. Two further tests cover the header checks, one from a codec of another dimension and one with a patched quant mode.

The wasm tier parity test now executes: wasm_simd128_tier_matches_the_reference ... ok under the WASI runner, which was not possible before the dev-dependency fix.

Tier coverage — what CI does and does not run

Both jobs in .github/workflows/test.yml run on ubuntu-24.04-arm, so CI exercises the NEON tier and no x86 tier. The x86 tiers are checked on an x86_64 host; the 512-bit tier additionally needs hardware or Intel SDE (sde64 -spr). Each x86 test returns early, with a printed note, on a host lacking the feature its tier needs. Closing the wider gap — CI running no x86 SIMD at all — is a workspace-level job, not this PR's.

Benchmarks

Re-measured on the rebased head (fluxbench, the repo norm), against a reconstruct-and-measure baseline:

	fused	baseline	ratio
dim 128	9.9 µs	60.4 µs	6.1×
dim 768	31.4 µs	318.9 µs	10.2×

A repeat run gave 9.4 µs at dim 128 (6.4×), so the dim-128 ratio is noisy at roughly 6.1–6.4×; dim 768 is stable at ~10×. Allocation tracking is installed: the fused path reports zero allocations, the baseline one Vec<f32> per candidate (13,107,200 B over 25,600 allocations at dim 128; 78,643,200 B at dim 768). Fixtures are built once per thread, outside the timed region.

The baseline approximates the pre-fusion pass rather than reproducing it — it uses a fixed 1/√dim scale instead of the candidate's stored corrective factor and reads the sign bits at a fixed header offset — so the ratio is indicative, not exact.

Known gaps (not covered by this PR)

• AVX-512 correctness is validated under Intel SDE only; no real-silicon performance numbers
• big-endian aarch64 has no prebuilt std, so the scalar-fallback path there is not compiled here
• the crate's wasm integration suite (tests/vector_suite) cannot build for wasm32: it targets collection, which is non-wasm by design. The lib tests do build and run
• no per-tier benches: only the dispatched tier is measured natively
• differential testing uses fixed seeds; there is no fuzz/property target for the kernel yet

Testing the 512-bit tier locally (no 512-bit hardware needed)

Intel SDE emulates the 512-bit paths — the same release rust-lang pins in its stdarch CI:

curl -LO https://ci-mirrors.rust-lang.org/sde-external-10.8.0-2026-03-15-lin.tar.xz
tar xf sde-external-10.8.0-2026-03-15-lin.tar.xz -C /opt
CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_RUNNER="/opt/sde-external-10.8.0-2026-03-15-lin/sde64 -spr --" \
  cargo nextest run -p nodedb-vector --lib distance::simd::bbq

Closes #280

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[farhan-syah]

Thanks. All ten points of the 2026-09-27 review are addressed, and the kernels are correct on every tier I traced: every load stays inside the guarded length, dim 0 and tails fall through to the bounds-checked scalar path, the lane-mask bit order is MSB-first on all four tiers, and there are no uninitialised reads. The zero-allocation claim holds by inspection. Three things block the merge; the rest is follow-up.

Blocking

1. The x86 tier functions are safe pub fns that can cause UB.
avx2::l2_bbq (distance/simd/avx2.rs:121) and avx512::l2_bbq (distance/simd/avx512.rs:106) call a #[target_feature] function after checking only the slice shapes. distance and simd::{avx2, avx512} are public, so safe code on an AVX2-only host can call nodedb_vector::distance::simd::avx512::l2_bbq(...) and execute AVX-512 instructions. That is the same class of defect as the length blocker, one step over: the shape is guarded, the CPU is not. The tests show it: // SAFETY: feature bit checked above. sits on safe calls (distance/simd/bbq.rs:206, :216, :240).

The existing l2_squared / cosine_distance / neg_inner_product in those two modules share the defect.

Fix: in distance/simd/mod.rs, make avx2 and avx512 pub(crate). Nothing outside the crate names them (nodedb and nodedb-lite have no caller); SimdRuntime::detect() and the in-crate tests still reach them. Then drop the // SAFETY: comments on the safe calls. neon (baseline on aarch64) and wasm_simd128 (compile-time gated) are sound as they are.

2. The new fluxbench dev-dependency makes the wasm tier untestable.
nodedb-vector/Cargo.toml:47 adds fluxbench under unconditional [dev-dependencies]; it pulls tokio, which does not build for wasm. That is why the crate's wasm tests cannot build (your "Known gaps"), so wasm_simd128_tier_matches_the_reference never runs — and this PR also switches wasm l2_squared / cosine_distance / neg_inner_product from scalar to the SIMD kernels, so those go untested too.

Fix: move it to [target.'cfg(not(target_arch = "wasm32"))'.dev-dependencies]. The wasm lib tests can then build under a wasm runner.

3. distance_prepared never checks the candidate header.
rerank/codecs/bbq.rs:174 reads the candidate through from_bytes but never compares header.dim or header.quant_mode with the codec. A stored candidate from another dimension or codec whose buffer is long enough yields a silently wrong distance. This predates the PR, but the PR rewrites this function, and a silently wrong result is not acceptable. Return RerankError::BadInput on a mismatch. While there, payload_len (:40) computes 4 + dim * 4 unchecked; use checked arithmetic.

Non-blocking

• CI claim. distance/simd/bbq.rs:9-11: both jobs in .github/workflows/test.yml run on ubuntu-24.04-arm (lines 39 and 108), so CI runs only the NEON tier — neither x86 tier, AVX2 included. Say that, and that the x86 tiers run only on an x86_64 host (AVX-512 only on hardware or SDE). bbq.rs:176 says "512-bit tiers" (plural); one remains.
• NEON load alignment. neon.rs:141-142 passes a *const f32 cast from an arbitrary &[u8] offset to vld1q_f32. It works with today's stdarch, but alignment is not a documented guarantee of that intrinsic. vreinterpretq_f32_u8(vld1q_u8(ptr)) is byte-aligned by definition.
• Big-endian aarch64. runtime.rs:112 selects neon::l2_bbq on any aarch64, including aarch64_be, where reinterpreting the little-endian payload gives wrong distances. The tests are gated target_endian = "little", which hides it. Select the scalar kernel when target_endian = "big".
• Bench. benches/bbq_kernel.rs: setup() (codec train plus 256 encodes) runs inside each bench function (line 71 and siblings); keep that state in thread_local! so only the kernel is timed. The unfused baseline ignores residual_norm and hard-codes offset 32, so it is an approximation of the old path. The doc comments describe history ("the path it replaces", "the removed path shape", lines 3-9 and 48); describe the baseline as what it is. Please re-run on 42abd92f7 or drop the 7.3× / 10.3× figures from the body.
• Scope in the PR body. wasm_simd128.rs was undeclared on main; this PR declares it and moves the wasm f32 kernels from scalar to SIMD in detect() (runtime.rs:120-134). That is correct — say so in the body.
• Nits. runtime.rs says "Fused BBQ kernels" (plural) on one field. The x86 tier tests return early and report PASS on a host without the feature.

Your two questions

The wasm simd128 tier: keep it. The gap is the Lite build, not this tier. nodedb-lite sets no simd128 anywhere (the shipped artifact is wasm-pack build --target web --release nodedb-lite-wasm with no flags), and nodedb-query's wasm SIMD tiers compile out of it the same way. Enabling +simd128 for the Lite wasm build is a follow-up in the Lite repo, not a blocker here.

AVX-512 verified under SDE only: acceptable for this PR; every other AVX-512 kernel in the repo is tested the same way. The real gap is wider — CI never runs any x86 SIMD code — and belongs in a separate workspace-wide x86_64 job (native AVX2 plus an sde64 -spr pass). Not your PR's job.

[EnRaiha]

All three blockers and the non-blocking list are addressed, rebuilt into one commit (64aa6f1eb). Thanks for tracing the kernels tier by tier — that is what made the remaining two defects legible.

Blocking

1. x86 tier functions were safe pub fns that could execute AVX-512. You were right, and the fix is the one you proposed: simd::avx2 and simd::avx512 are now pub(crate), with a comment in mod.rs recording why (the entry points are safe pub fns calling #[target_feature] implementations, so exporting the module lets safe code run AVX-512 on a host without it; SimdRuntime::detect() is the only supported path). I checked nothing outside the crate names them. The // SAFETY: comments on the safe calls are gone — replaced by a note that the feature check above is what keeps the test off a host without the feature. neon and wasm_simd128 stay public as you said.

2. fluxbench — worse than one layer. Moved to [target.'cfg(not(target_arch = "wasm32"))'.dev-dependencies]. With tokio gone the wasm lib test build then failed on two further pre-existing gates: a test in hnsw/graph/index/state.rs importing segment_backing (gated off on wasm at lib.rs:61) and another importing get_vector_or_backing (gated at vectors.rs:64). Both now carry #[cfg(not(target_arch = "wasm32"))], as does the Arc import only they use.

The wasm lib suite now builds and runs: 374 passed, 0 failed on wasm32-wasip1 +simd128 under Node 22's WASI runner, and wasm_simd128_tier_matches_the_reference executes for the first time.

One caveat I want to state rather than bury: I removed the wasm_simd128_rejects_empty_slices should_panic case I had added last round. On wasm32 the panic strategy is abort, so libtest reports #[should_panic] as ignored — it could never fail on its only target, which is the defect you flagged twice already. The guard stays covered by the native per-tier cases and the crate's simd_length_safety suite. The two scalar should_panic cases still run natively; they appear as ignored only inside the wasm run.

3. distance_prepared header validation. It now rejects a candidate whose header.dim or header.quant_mode disagrees with the codec, and payload_len is checked arithmetic returning Option. Two tests cover it: one scores a candidate from a codec of twice the dimension — long enough to parse against this codec's packed length, so only the header check can catch it — and one patches the quant-mode bytes to Sq8.

Non-blocking

• CI claim rewritten: both jobs are ubuntu-24.04-arm, so CI runs the NEON tier and no x86 tier; the x86 tiers are checked on an x86_64 host and the 512-bit tier under SDE. "512-bit tiers" is now singular.
• NEON alignment: loads are vreinterpretq_f32_u8(vld1q_u8(ptr)), byte-aligned by definition, with the reason in a comment.
• Big-endian aarch64: the detect() arm and its use are gated target_endian = "little", so aarch64_be falls through to the scalar kernel. I could not compile-verify it — aarch64_be-unknown-linux-gnu ships no prebuilt std — so the body records it as inspection-only rather than implying it was built.
• Bench: fixtures moved to thread_local! per dimension, so setup is outside the timed region; the module doc now describes the baseline as what it is (an approximation — fixed 1/√dim scale, fixed header offset) instead of narrating history. Re-ran on this revision: 6.4× at dim 128 and 10.2× at dim 768 (previously 7.3× / 10.3×). The body carries the measured numbers plus the approximation caveat, so nothing is carried over unstated.
• Scope: the body now says that wasm_simd128 was undeclared on main and that this PR declares it and moves the wasm f32 kernels from scalar to SIMD in detect().
• Nits: the l2_bbq field doc is singular. On the early-return skips — nextest has no dynamic skip, and gating the test on #[cfg(target_feature)] would break the SDE path, so the runtime check with its printed note stays; the module doc now explains that explicitly.

Your two questions

Both taken, thank you: the wasm tier stays (the gap is the Lite build, and enabling +simd128 there is a Lite-repo follow-up), and SDE-only for AVX-512 is fine with the workspace-wide x86_64 CI job as a separate item.

Evidence on 64aa6f1eb: cargo nextest run -p nodedb-vector --all-features --cargo-profile ci --profile ci → 468 passed, 0 failed; wasm lib suite → 374 passed under Node's WASI runner; cargo check --workspace --all-features clean; cargo fmt --all --check and cargo clippy -p nodedb-vector --all-targets -- -D warnings clean; aarch64-unknown-linux-gnu and wasm32-wasip1 (with and without +simd128) clean; nodedb-preflight.sh pass.

[farhan-syah]

Requesting changes for one clippy error. All ten points from the previous review landed.

Previous review

Point	Status
B1: avx2 / avx512 crate-private, // SAFETY: removed from safe calls	Landed
B2: fluxbench non-wasm dev-dependency	Landed
B3: candidate header.dim / quant_mode checks, checked payload_len	Landed, with two rejection tests and a value test
CI claim in the bbq.rs module doc	Landed
NEON unaligned load	Landed
Big-endian aarch64 dispatch	Landed
Bench fixtures, baseline wording, re-run figures	Landed
Scope stated in the PR body	Landed
Nits	Landed. The x86 early return is now documented, which is enough.

What I ran on 64aa6f1eb

Check	Result
cargo fmt --all --check	clean
cargo nextest run -p nodedb-vector	508 passed, 0 failed
cargo clippy -p nodedb-vector --all-targets -- -D warnings (rustc 1.98.1 stable)	1 error

Blocking

rerank/codecs/bbq.rs:309 fails clippy::chunks_exact_to_as_chunks. Details inline.

test.yml runs clippy on stable with -D warnings, so CI fails on this line. Your clippy run used an older toolchain that lacks the lint.

This is the last blocker. Fix it and the PR is ready to approve.

[farhan-syah]

clippy::chunks_exact_to_as_chunks rejects this on stable (rustc 1.98.1):

error: using `chunks_exact` with a constant chunk size
   --> nodedb-vector/src/rerank/codecs/bbq.rs:309:14
    = note: `-D clippy::chunks-exact-to-as-chunks` implied by `-D warnings`

Replace it with .as_chunks::<4>().0.iter(). The removed decode_payload used the same form.

[EnRaiha]

Fixed, and verified under the toolchain that caught it. Rebuilt as one commit (08032f2a2).

The blocker

rerank/codecs/bbq.rs:309 now uses .as_chunks::<4>().0.iter(), exactly as you prescribed — the same form the bench already used. I swept the class rather than the line: grep -rn chunks_exact across nodedb-vector/{src,tests,benches} returns nothing.

Why my run missed it — both causes are mine to fix

Toolchain. My local clippy was 0.1.96 (rustc 1.96.1); CI's stable is 0.1.98 (1.98.1), and chunks_exact_to_as_chunks does not exist in 1.96.1. I have now installed 1.98.1 locally and re-run CI's literal command:

cargo clippy --workspace --all-targets --all-features --profile ci -- -D warnings   # test.yml:58
→ Finished `ci` profile, exit 0

Clean, so the fix holds under the toolchain that rejected it.

Scope. CI runs the whole workspace; you ran -p nodedb-vector and so did I. Both narrower than CI. Worth noting what the wider scope turned up on 1.96.1: one error in nodedb/src/control/planner/sql_plan_convert/dml/vector_primary.rs:161 ("this boolean expression can be simplified"). That file is untouched here (the diff is nodedb-vector/**, .github/workflows/fuzz.yml, Cargo.lock) and byte-identical to main, so it is pre-existing — and it does not reproduce on 1.98.1, which is why your run saw only my line. FYI only: on an up-to-date toolchain the workspace is clean, so there is nothing to chase there.

Also in this revision

CI coverage for this crate (the one non-code change). fuzz.yml's path filter did not list nodedb-vector, so no CI job built it for a 32-bit target — for a PR that changes its wasm dispatch. The filter now includes it, and the wasm32-decoders job builds nodedb-vector for wasm32-wasip1 in both SIMD modes (without the flag to prove the scalar fallback compiles, with it to compile the vector kernels). It cannot use wasm32-unknown-unknown as the decoder crates do: nodedb-vector has no getrandom backend there, so a check on that target cannot pass. Happy to split this into its own PR if you would rather keep this one to the kernel.

Test Suite run locally. Since it is opt-in and this PR carries no label, I ran its exact command on 08032f2a2: cargo nextest run --workspace --exclude nodedb-cluster-tests --all-features --cargo-profile ci --profile ci → 16,865 passed, 0 failed, 0 skipped. One flaky retry, nodedb::wire cases::graph_dsl_algo::graph_algo_edge_label_excludes_unmatched_edge_types, unrelated to this change.

One request

Could a maintainer add the run-ci label to this PR? The full suite is opt-in (ci.yml:4-12) and this account has no triage permission, so it reports as skipped. Given the change touches unsafe and a public API, and the checks that do run automatically are the same set that was green on the previous head with the out-of-bounds blocker still in it, having the suite on the record seems worth it. If you would rather not, the local run above is the substitute.

[EnRaiha]

Correction to the CI change I described in my last comment, pushed as 2c3545156.

I had widened fuzz.yml's path filter to include nodedb-vector. It worked — the workflow fired — but it contradicts that file's own stated intent: its header says the filter exists so the workflow runs "only when a change can reach a decoder", and it lists only crates a fuzz target can reach. Widening it made six ASan jobs run on this PR, none of which a change to nodedb-vector can affect. You can see them on the previous head.

So I reverted fuzz.yml and gave the crate its own workflow instead: .github/workflows/wasm-vector.yml, triggered on nodedb-vector/** and on itself only. It builds the crate for wasm32-wasip1 in both SIMD modes — without the flag to prove the scalar fallback still compiles, with it to compile the vector kernels. wasm32-unknown-unknown is not usable here: nodedb-vector has no getrandom backend for it, so a check on that target cannot pass.

Everything else in 2c3545156 is as described: the chunks_exact fix, verified clean under 1.98.1 with CI's literal workspace clippy command, and the local workspace suite at 16,865 passed / 0 failed.

Still happy to split the workflow into its own PR if you would rather keep this one to the kernel — it is the one change here that is not about the code.

[farhan-syah]

The clippy fix landed. cargo clippy -p nodedb-vector --all-targets -- -D warnings is clean on rustc 1.98.1, and cargo nextest run -p nodedb-vector passes 508/508.

Blocking

Remove .github/workflows/wasm-vector.yml from this PR. Do not move it to a separate PR either. We do not want this workflow.

• wasm32-wasip1 is the wrong target. Lite ships nodedb-vector on wasm32-unknown-unknown through nodedb-lite-wasm.
• The reason given for wasip1 is wrong. nodedb-vector builds for wasm32-unknown-unknown once getrandom has a JS backend. The missing backend comes from nodedb-types (aes-gcm → rand_core → getrandom 0.2), not from this crate.
• This PR is the fused kernel. CI changes are out of scope.

With the workflow removed, this is ready to approve.

[EnRaiha]

Removed. .github/workflows/wasm-vector.yml is gone from the branch (8d74580cb), and I am not opening a separate PR for it.

You are right on the diagnosis, and I verified it rather than taking it on trust:

$ cargo tree -p nodedb-vector --target wasm32-unknown-unknown -i getrandom@0.2
getrandom v0.2.17
└── rand_core v0.6.4
    └── crypto-common ← aead ← aes-gcm v0.10.3
        └── nodedb-types v0.5.0

The 0.2 copy arrives through nodedb-types, so the missing backend is inherited, not a property of this crate. The justification I wrote in that file — "nodedb-vector has no getrandom backend there" — was false, and wasm32-wasip1 was the wrong target on top of it. Lite ships this crate on wasm32-unknown-unknown, which is the target that matters.

CI changes were out of scope and I should have left the observation as a comment instead of acting on it. That is the second CI claim I have had to withdraw on this PR — the first was the fuzz.yml filter widening, which I caught myself and corrected. The pattern is that I have been reasoning about CI from a local build rather than from how the artifact is actually produced.

The PR is code only now: nodedb-vector/** plus Cargo.lock, 13 files. The chunks_exact fix and everything from the previous round are unchanged.

[EnRaiha]

CI's Test Suite came back red on this head, in Run cluster tests. I ran it down before reporting, and it is not this change.

What failed — two nodedb-cluster-tests cases:

• cases::calvin_multishard_pk_read::cross_node_pk_read_from_learner_node_after_calvin_commit (all 4 retries)
• cases::linearizable_read_leadership::an_eventual_read_is_still_served_without_a_quorum

Both are Raft membership/leadership assertions. The panic is:

calvin_multishard_pk_read.rs:123:5: node 4 must join tagfold_nm_a's group 2 as a learner:
node 4 g2: role=Follower leader=1 term=1 commit=20 applied=20 last_log=21 snap=0 members=3 learners=0

Evidence that it is pre-existing:

1. It reproduces with this PR reverted. I restored nodedb-vector and Cargo.lock to 1ff35512b — no PR change in the tree — and ran the same test filter: TRY 4 FAIL on the same assertion, 7 tests run: 6 passed, 1 failed, error: test run failed. Same signature, same retry exhaustion, same step.
2. It is flaky, not deterministic. With the change in the tree, the same test failed TRY 1–3 locally and passed TRY 4.
3. No vector involvement. grep -i vector in calvin_multishard_pk_read.rs returns nothing; this PR changes a distance kernel and a codec guard, neither of which is on the membership path.
4. The harness already waits. add_learner_node (nodedb-test-support/src/cluster_harness/cluster/membership.rs:60) waits 30s for topology convergence and then for full-apply convergence, so this is not a missing wait in the test — the learner-join path itself is where the group ends up with learners=0.

Everything else on this head is green: Lint & Check (including Run clippy on your toolchain), Analyze Rust, CodeQL, Gitleaks, Static gates.

I am not proposing to fix it in this PR — it is a cluster-test flake in nodedb-cluster-tests, and calvin_multishard_pk_read.rs:123 is the assertion rather than anything under this change. Flagging it because you added the label and will see the red. Happy to open a separate issue for the learner-join convergence if that is useful.

[farhan-syah]

Rebase from main #392 is green.

[EnRaiha]

Rebased onto current main (f18b31edf) — 65 commits, which had moved nodedb-vector substantially (64 files, +3958/−1522). Rebuilt as one commit, fff126479.

Conflicts: none. Only two of my files overlapped anything on main — Cargo.lock and hnsw/graph/index/state.rs (where I gate two tests and their Arc import for wasm32) — and both merged cleanly. The other eleven files were untouched on main.

Re-validated on the rebased tree:

Check	Result
cargo nextest run -p nodedb-vector --all-features	511 passed, 0 failed (was 468 — main added tests)
cargo clippy --workspace --all-targets --all-features --profile ci -- -D warnings on 1.98.1	clean, exit 0
cargo fmt --all --check	clean
wasm32-wasip1 with and without +simd128	clean both ways
aarch64-unknown-linux-gnu	clean
nodedb-preflight.sh	pass

The diff against main is unchanged in content: 13 files, +886/−58.

One note on the earlier CI result: the Test Suite / Test failure on 8d74580cb was in Run cluster tests, and it reproduces with this PR reverted — nodedb-vector and Cargo.lock restored to 1ff35512b fails the same assertion (calvin_multishard_pk_read.rs:123, members=3 learners=0) on all four retries. Unrelated to this change, but it will likely show red again on the new head for the same reason.