Files
Dragan Spiridonov da638f9079 feat(kernel): migrate NativeHnswBackend from @ruvector/router to hnswlib-node (#399)
@ruvector/router 0.1.28 was found to have four serious bugs that
together broke production code-intelligence semantic search and
forced the v3.9.5 hotfix to disable native HNSW entirely:

  1. HNSW search returned essentially random results — recall@10 was
     0% on the project's FNV fixture and 10% on textbook unit-Gaussian
     random vectors. The graph walk could not even find self-vectors
     when querying with a stored vector. Reproduced deterministically
     on linux-arm64; matches the linux-x64 GitHub Actions failures
     reported in #399.
  2. The VectorDb constructor unconditionally wrote a `vectors.db`
     redb file to the current working directory, polluting users'
     project roots with multi-MB files outside .agentic-qe/, in a
     non-SQLite format that no AQE migration or backup tooling knew
     about. Direct violation of the unified memory architecture.
  3. The redb file held a process-wide exclusive lock — only ONE
     VectorDb instance could exist per process. Subsequent constructors
     threw "Database error: Database already open. Cannot acquire lock."
  4. NAPI dispose did not synchronously release the redb lock (NAPI GC
     is not synchronous). The lock outlived dispose() and caused the
     v3.9.5 futex deadlock when the indexer tried to recreate after
     reset.

NativeHnswBackend is rewritten to wrap hnswlib-node@^3.0.0 — the
canonical Node.js binding for Yury Malkov's reference C++ Hnswlib
implementation, used by Pinecone, Weaviate, Qdrant, LangChain, and
ChromaDB. Empirical verification on the same fixture
(`scripts/diagnose-issue-399*.mjs`):

  - hnswlib-node:        recall@10 = 100%, top-1 = id 42 ✓
  - @ruvector/router:    recall@10 =  10%, top-1 = id 999 (random)

Insert is also faster (~324ms vs ~430ms for 1k vectors) and search
is comparable (0.35ms vs 0.21ms with correct vs wrong results).

No new dependency was added — `hnswlib-node` was already a direct
dependency in `package.json` from the legacy code path in
`src/integrations/embeddings/index/HNSWIndex.ts`.

Implementation notes:

  - Drops the local `vectorStore` mirror that the previous backend
    needed to re-score wrong native results — hnswlib-node returns
    correct distances directly.
  - Drops the `bruteForceSearch` private fallback — there is no
    fallback path because hnswlib-node always returns correct results.
  - `clear()` now recreates the underlying HierarchicalNSW from
    scratch instead of just markDelete-ing every label. The
    tombstone-only approach leaks state across long test runs that
    share the singleton HnswAdapter registry, producing duplicate
    labels from `searchKnn` after many cycles.
  - `search()` overshoots k by 2x and dedups by id as a defensive
    measure against any future hnswlib-node duplicate-label edge
    case, then truncates back to k.
  - `add()` doubles maxElements via `resizeIndex()` when the live id
    count fills the current capacity, so callers don't need to know
    the final index size at construction time.
  - `useNativeHNSW` default flipped back to `true`. Users with large
    codebases get sublinear HNSW search by default again.
  - All four `@ruvector/router` failure modes have explicit regression
    guards in the unit and integration test suites.

The two #399-skipped tests in `phase1-integration.test.ts`
(line 222 and 1185) are un-skipped and now pass green against the
new backend. The three flag-default tests that asserted
`useNativeHNSW: false` (broken by v3.9.5's hotfix) are updated to
assert `true` again.

Stale comments referencing `@ruvector/router`'s lock behavior are
updated in `src/kernel/unified-memory.ts`, `src/init/phases/06-code-intelligence.ts`,
`src/init/phases/10-workers.ts`, and `src/cli/index.ts`. The CLI
status output (`aqe ruvector status`) and the `useNativeHNSW` flag
description are updated to mention `hnswlib-node` instead of
`@ruvector/router`.

Refs #399, ADR-090.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-06 18:22:24 +00:00
..
2026-04-05 18:51:49 +02:00
2026-04-05 18:51:49 +02:00
2026-04-05 18:51:49 +02:00