mem0ai/mem0 · error · Error

Unsupported Neptune Analytics filter operator: ${operator}

Error message

Unsupported Neptune Analytics filter operator: ${operator}

What it means

Operator objects dispatched in buildOperatorFilter (the switch that maps operator names to Neptune filter shapes) fall through to a default case that throws, listing the unsupported operator. Only a whitelist (eq/in/notIn/contains/startsWith and similar) is implemented; anything else (gte, lte, ne, regex, icontains...) has no Neptune translation.

Source

Thrown at mem0-ts/src/oss/src/vector_stores/neptune_analytics.ts:659

        return {
          stringContains: {
            property: key,
            value: operand,
          },
        };
      case "startsWith":
        return {
          startsWith: {
            property: key,
            value: operand,
          },
        };
      case "icontains":
        throw new Error(
          "Neptune Analytics vector search does not support case-insensitive contains filters.",
        );
      default:
        throw new Error(
          `Unsupported Neptune Analytics filter operator: ${operator}`,
        );
    }
  }

  private negateVertexFilter(filter: NeptuneVertexFilter): NeptuneVertexFilter {
    if (Array.isArray(filter.andAll)) {
      return this.combineVertexFilters(
        "orAll",
        filter.andAll.map((entry: NeptuneVertexFilter) =>
          this.negateVertexFilter(entry),
        ),
      )!;
    }

    if (Array.isArray(filter.orAll)) {
      return this.combineVertexFilters(
        "andAll",

View on GitHub (pinned to 001c235229)

Solutions

  1. Rewrite the filter using supported operators (equality, in, contains, startsWith) or plain field equality.
  2. Over-fetch with supported filters, then apply gte/lte/regex client-side on payloads.
  3. For rich querying, move the data to a provider that supports the operators (postgres/qdrant) or query Neptune with openCypher directly.

Example fix

// before
store.search(q, 50, { ts: { gte: 1700000000 } }); // throws: Unsupported operator

// after
const res = await store.search(q, 50, { user_id: 'u1' });
const filtered = res.filter(r => (r.payload?.ts ?? 0) >= 1700000000);
Defensive patterns

Strategy: validation

Validate before calling

const SUPPORTED = new Set(['eq', 'in', 'notIn', 'contains', 'startsWith']);
function findUnsupportedOps(node: any, path = ''): string[] {
  const bad: string[] = [];
  for (const [k, v] of Object.entries(node ?? {})) {
    if (v && typeof v === 'object' && !Array.isArray(v)) {
      for (const op of Object.keys(v)) if (!SUPPORTED.has(op)) bad.push(`${path}${k}.${op}`);
    }
  }
  return bad;
}

Type guard

const isSupportedNeptuneOp = (op: string): boolean =>
  ['eq', 'in', 'notIn', 'contains', 'startsWith'].includes(op);

Try / catch

try { results = await store.search(q, k, filters); }
catch (e) {
  if (e instanceof Error && e.message.startsWith('Unsupported Neptune Analytics filter operator')) {
    // downgrade unsupported ops (gte/lte/regex) to client-side post-filtering
  } else throw e;
}

Prevention

When it happens

Trigger: Passing { ts: { gte: 1700000000 } }, { name: { regex: 'a.*' } }, { n: { between: [1,2] } } or any operator string outside the supported set; typos in operator names ('startswith' vs 'startsWith'); generic operator vocabularies from other providers reused against Neptune.

Common situations: Porting range/comparison filters from SQL-backed stores; LLM-generated filter operators; version drift if operator names change between Python and TS providers.

Related errors


AI-assisted analysis of mem0ai/mem0@001c235229 (2026-08-15). Data as JSON: /api/errors/69f7b23f6f1fcec8. Report an issue: GitHub.