fix(hnsw): skip corrupt nodes instead of crashing on decode errors

[kriszyp]

Summary

• Adds a private safeGetSync helper on HierarchicalNavigableSmallWorld that wraps indexStore.getSync in a try-catch, returning undefined (and logging a warning) instead of propagating the error when a node's stored bytes are corrupt.
• Applies it to all 7 call sites that read node data by numeric key: getEntryPoint, the entry-point read in index(), the old-node neighbor removal loop, the connectionsToBeReplaced loop, addConnection, searchLayer, and checkSymmetry.
• Fixes a pre-existing bug in checkSymmetry that logged the undefined result instead of the key.
• Adds a unit test using a minimal mock store that throws "Data read, but end of buffer not reached 0" after the third neighbor access, asserting doesNotThrow on subsequent inserts.

Purpose

A single corrupt HNSW node in a customer's index (User app, confirmed raw bytes 01010101449100000e0000...) was causing indexStore.getSync to throw an unhandled exception in graph traversal. That uncaught exception triggered a worker uncaughtException → RocksDB napi_call_threadsafe_function on dead thread → SIGSEGV → full process crash. Every subsequent insert to an HNSW-indexed table re-hit the same corrupt node and crashed again, creating a crash loop.

The fix makes corrupt nodes non-fatal: they are skipped during traversal with a warning log. The graph remains operational (potentially with degraded routing near the corrupt node) until the index is rebuilt.

Areas requiring attention

• Coverage completeness: there are exactly 7 places that call getSync with a numeric key. I believe all are now covered by safeGetSync, but please verify against the full index() method, especially the level-iteration loop around line 150–180, which was the hardest to reason about.
• Swallowed corruption: safeGetSync silently continues when a node is unreadable. This means a corrupt node in the path from the entry point could cause the search to explore a smaller portion of the graph. The logged warning at warn level should surface this, but consider whether error level is more appropriate.
• Unit test mock fidelity: the mock indexStore key dispatch (Symbol → entryPoint, number → node, JSON-stringified → level connection lists) mirrors the real store's key pattern. If that pattern changes, the test could silently stop exercising the corrupt path.
• Two commits on branch: the first commit (047744bf8) has verbose per-site try-catch blocks; the second (4b9e22bab) refactors to the safeGetSync helper. Squash on merge is fine.

Test plan

• npm test -- --grep 'does not crash when an index node decodes as corrupt' passes
• Full HNSW test suite (vectorIndex.test.js) passes (3 integration tests + new unit test)
• Deploy 5.0.10 patch to Serent nodes and confirm crash loop stops
• After stabilisation, rebuild HNSW indexes for DocumentChunk, CompanyProfile, ScoreEvidence to evict the corrupt node

🤖 Generated with Claude Code

[claude]

Missed safeGetSync call site — update path still crashes on corrupt nodes

nodeId is always numeric here (either from Atomics.add or from the safeKey lookup), so this is one of the numeric-key node reads the PR set out to protect. If the stored bytes for this node are corrupt, getSync throws before the spread runs, and the exception propagates through index() exactly as before the fix — defeating the crash-loop protection on the update (existingVector) path.

Suggested change

	oldNode = { ...this.indexStore.getSync(nodeId, options) };
	oldNode = { ...this.safeGetSync(nodeId, options) };

The PR description counts "exactly 7 places that call getSync with a numeric key"; this is the one that was missed.

[claude]

One blocker: resources/indexes/HierarchicalNavigableSmallWorld.ts line 112 has a raw this.indexStore.getSync(nodeId, options) in the existingVector (update) branch of index() — the one numeric-key node read not converted to safeGetSync. A corrupt node on the update path will still throw and re-enter the crash loop. See inline comment.