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]

Reviewed; no blockers found. The prior blocker (raw getSync on the update-path in index()) is addressed in commit d8b0846f6.

[cb1kenobi]

LGTM

[kriszyp]

LGTM

False. We both hate it. But whatever, could help in some situations.