fix(sessions): match non-ASCII content in AdvancedSQLiteSession search

[LeSingh1]

The bug

AdvancedSQLiteSession.find_turns_by_content() never matches non-ASCII content.

Session rows are stored with json.dumps(item), which escapes every non-ASCII character as \uXXXX. The search then does ... AND am.message_data LIKE ? with the raw term, so the term and the stored bytes can never line up. A user who stores a Japanese conversation and searches it for a Japanese word gets an empty list, with no error.

create_branch_from_content() searches the same column, so it fails the same way — you can't branch from a non-ASCII turn.

Repro on main

>       assert [turn["turn"] for turn in await session.find_turns_by_content("東京")] == [1]
E       assert [] == [1]
E         Right contains one more item: 1
tests/extensions/memory/test_advanced_sqlite_session.py:1829: AssertionError
1 failed in 0.90s

The fix

Re-encode the search term with json.dumps before building the LIKE pattern, so it is in the same encoding as the column. ASCII searches are byte-identical to before. This also fixes terms containing " or \, which were escaped in storage but not in the query.

With the fix, that test passes and the full file is green:

1 passed in 0.45s
129 passed in 8.55s

ruff check, ruff format --check and mypy are clean on both files.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 596f1f30b4

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[seratch]

The JSON encoding fix correctly makes non-ASCII content searchable, but it also makes SQLite LIKE metacharacters in those newly reachable searches active.

For example, a search term containing % or _ can match a different turn than the literal content requested, and create_branch_from_content() can consequently branch from the wrong turn. Please escape %, _, and the chosen escape character in the encoded needle, use an explicit LIKE ... ESCAPE ... clause, and add regression coverage combining non-ASCII text with literal % and _.

[LeSingh1]

Good catch — done, all three.

_stored_message_data_needle now escapes the escape character first, then % and _, and the query uses LIKE ? ESCAPE '\'. Doing the escape character first matters: the other order double-escapes it. It composes correctly with the JSON encoding, since \uXXXX in the encoded needle becomes \\uXXXX in the pattern, which under ESCAPE '\' means a literal backslash followed by uXXXX — exactly what is stored.

Worth noting the wildcard behaviour was there before this PR; what my change did was make it reachable for non-ASCII terms, which is how you spotted it. So the fix covers ASCII terms too — "50%" no longer matches a turn containing 5000.

New test combines non-ASCII with literal % and _:

find_turns_by_content("50%")  -> [1]   (not the "5000" turn)
find_turns_by_content("a_b")  -> [3]   (not the "axb" turn)
find_turns_by_content("%")    -> [1]   literal percent, not "match everything"
find_turns_by_content("_")    -> [3]

One thing I got wrong on the first pass and corrected: I had asserted a bare "%" should return nothing. It should return the turn that literally contains a percent sign, which is what it does.

130 passed in the file. ruff check, ruff format --check, and mypy are clean.

[seratch]

Thanks for addressing the LIKE wildcard escaping. One correctness issue remains: searching for é also matches a message containing the literal text \u00e9. Its stored JSON contains \\u00e9, and the encoded search needle can match starting at the second backslash. Since matching rows are accepted without checking decoded content, create_branch_from_content("é") can select an earlier turn that does not contain é.

Please validate candidate matches against decoded message content and add a regression with an earlier literal-escape turn followed by an actual Unicode turn. Verify that search returns only the actual Unicode turn and that content-based branching uses that turn.