PineconeFilterExpressionConverter corrupts $in/$nin operators on Turkish locale

[Dpk376]

Bug description

PineconeFilterExpressionConverter builds Pinecone metadata-filter operators by lowercasing the Filter.ExpressionType enum name without specifying a Locale:

private String getOperationSymbol(Expression exp) {
    return "\"$" + exp.type().toString().toLowerCase() + "\": ";
}

exp.type().toString() is always the uppercase enum constant. On a JVM running the Turkish locale (tr_TR), "IN".toLowerCase() returns "ın" (dotless ı) and "NIN".toLowerCase() returns "nın", so the converter emits "$ın" / "$nın" instead of "$in" / "$nin". These are not valid Pinecone operators, so any metadata filter using IN / NIN fails on Turkish-locale JVMs.

Environment

• Spring AI: main (2.0.0-SNAPSHOT); the pattern also exists in 1.x
• JVM locale: tr_TR

Steps to reproduce

Run with -Duser.language=tr -Duser.country=TR and convert an IN filter:

new PineconeFilterExpressionConverter()
    .convertExpression(new Expression(IN, new Key("genre"), new Value(List.of("comedy", "drama"))));
// expected: {"genre": {"$in": ["comedy","drama"]}}
// actual:   {"genre": {"$ın": ["comedy","drama"]}}

Expected behavior

Operator symbols are protocol tokens and must be locale-independent. The conversion should use Locale.ROOT.

Related

Same bug class as #5340 (Gemini tool type normalization) and #6476 / #6477 (OpenAI protocol values). This is a different, unreported code path in spring-ai-vector-store.

[jewoodev]

Thanks for reporting this and opening #6479.

One small process note: CONTRIBUTING.md says under "Should you create an issue first?" that if you're ready to submit the fix, you can open the pull request directly and use the PR description to provide the same context and motivation. An issue is only needed when you want to start a discussion first.

For future contributions like this, opening just the PR would help keep the discussion and review in one place.