Fix escaping issue in filterExpression for RedisVectorStore file name

[kmw10693]

Issues#2945

Problem

When using SearchRequest.Builder#filterExpression(String) in a Redis-backed vector store, expressions that include file names such as 'java编程思想.pdf' or Windows-style paths like 'C:\\docs\\file.txt' cause parsing errors due to unescaped special characters (e.g., . or \).

These characters are treated as operators or escape tokens by the internal parser, leading to failures when the input is passed directly to FilterExpressionTextParser.

Changes Introduced

Introduced an internal escapeTextExpression(String) method in SearchRequest.Builder to automatically escape:

• Backslashes (\) → \\
• Dots (.) → \.
• Applied this escaping inside filterExpression(String) before parsing via FilterExpressionTextParser.
• This escaping is applied only within single-quoted string literals to preserve the overall filter expression syntax.

[markpollack]

Thanks for the PR, I am afraid to merge this due to unintended sdie effects right before the release. Anything with Regex is always a difficult thing to deal with and make sure it is correct.

[kmw10693]

@markpollack

Hi, thank you for the thoughtful feedback — I completely understand your concern about introducing regex-related changes right before a release. It's true that regex-related logic can be tricky and prone to side effects if not carefully verified.

To help mitigate this, I’ve added comprehensive test coverage focused on exactly the kind of edge cases that could cause parsing issues. Specifically, the tests ensure that string literals containing dots (.) and backslashes () are properly escaped only within quoted strings, and not elsewhere in the expression.

Here are the cases covered:

Dot and backslash escaping inside file names and paths:

file_name == 'clean.code.pdf' && path == 'C:\\docs\\files'

Multiple independent literals with dots:

file_name == 'a.b.c' && author == 'me.you'

Various file extensions:

'summary.epub', 'lecture_notes.md', 'slides.pptx'

List-style IN clause handling:

file_name IN ['a.pdf', 'b.txt', 'final.report.docx']

Each test verifies that escaping is applied consistently and correctly. I'm happy to improve test coverage further if that’s preferable.

Thanks again for the review 🙏

[injae-kim]

static Map<String, String> escapeText = {
  // from, to
  "\\", "\\\\",
  ".", "\\."
}

nit. how about extracting escape target texts to variable?
maybe we need more escape text pattern in the future.

[kmw10693]

@markpollack
I've replaced the Regex with a simpler and more maintainable approach using a constant-based escape map and StringBuilder. This avoids potential side effects while making it easier to extend or audit in the future.