While implementing a feature (AI-assisted) I came upon an issue. LLM content incoming...

Version

arcadedb-26.1.1-SNAPSHOT (Observed in local fork; likely present in upstream at this revision).

Summary

The vectorNeighbors function fails when used on an LSM_VECTOR index created for a DOCUMENT type, resulting in a RecordNotFoundException (HTTP 500).

The issue stems from SQLFunctionVectorNeighbors explicitly calling rid.asVertex(). When the record is a Document rather than a Vertex, the underlying ClassCastException is caught and re-thrown as a RecordNotFoundException, even though the record exists.

Reproduction Steps

-- Setup Schema
CREATE DOCUMENT TYPE Doc IF NOT EXISTS;
CREATE PROPERTY Doc.name IF NOT EXISTS STRING;
CREATE PROPERTY Doc.embedding IF NOT EXISTS ARRAY_OF_FLOATS;

-- Create Vector Index
CREATE INDEX IF NOT EXISTS ON Doc (embedding) LSM_VECTOR 
METADATA { dimensions: 3, similarity: 'COSINE' };

-- Insert Data
INSERT INTO Doc SET name = 'docA', embedding = [1.0, 0.0, 0.0];
INSERT INTO Doc SET name = 'docB', embedding = [0.9, 0.1, 0.0];

-- Query (Fails here)
SELECT vectorNeighbors('Doc[embedding]', [1.0, 0.0, 0.0], 2) as neighbors;

Expected Behavior

vectorNeighbors should support multi-model usage. It should return Document records (or RIDs) without throwing an exception when used on Document types.

Actual Behavior

The query fails with an HTTP 500 error and the following server log:

RecordNotFoundException: Record #x:y not found
Error on executing command

Root Cause Analysis

The failure occurs in SQLFunctionVectorNeighbors.java:

final RID rid = neighbor.getFirst();
final Vertex vertex = rid.asVertex(); // This line fails for Document records

In RID.asVertex(), the code attempts a cast:

return (Vertex) database.lookupByRID(this, loadContent);
// Any exception here is caught and wrapped as a RecordNotFoundException

Proposed Fix

Materialize the neighbors based on the actual schema type to ensure compatibility with non-vertex documents:

// Logic to determine if the result should be treated as a vertex or a generic document
if (returnVertex) {
    result.add(Map.of("vertex", rid.asVertex(), "distance", distance));
} else {
    result.add(Map.of("record", rid.asDocument(), "distance", distance));
}

Why this is safe:

• Non-breaking: It preserves the existing output shape for current Vertex-based implementations.
• Enabling: It expands functionality to Document types that are currently completely broken.

Human again: I prefer not to submit AI PRs unless the maintainers explicitly tolerate such things, and the issue could contain a misunderstanding. I'm moving too fast at the moment to scrutinize.

Potentially Related:

#1302
#2801