From 9e394ed9142fdb43773e8f13e55192962e1d7430 Mon Sep 17 00:00:00 2001
From: Trenton Holmes <797416+stumpylog@users.noreply.github.com>
Date: Tue, 18 Aug 2026 14:11:11 -0700
Subject: [PATCH] refactor(search): log the CJK clause's skip path like the
 fuzzy clause's

_build_cjk_query silently swallowed a parse failure with no log line,
while _try_parse_fuzzy_query logs at debug for the same "skip this
optional clause" situation. Add the matching debug log.

Deliberately NOT narrowing except Exception to except ValueError here to
match the fuzzy path: the fuzzy blend's word string is pre-filtered to
\\w+-only tokens before it ever reaches index.parse_query, so ValueError
is the only realistic failure mode there. cjk_text has no equivalent
filter, so narrowing this catch without verifying tantivy's actual
exception behavior for CJK input would risk letting something other than
ValueError propagate uncaught - the same class of mistake as the fuzzy
blend regression this migration already fixed once, in the other
direction.
---
 src/documents/search/_query.py | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/src/documents/search/_query.py b/src/documents/search/_query.py
index 1565e581d..8da2470c4 100644
--- a/src/documents/search/_query.py
+++ b/src/documents/search/_query.py
@@ -155,6 +155,14 @@ def _build_cjk_query(
     try:
         return index.parse_query(cjk_text, fields)
     except Exception:
+        # Broad on purpose, unlike _try_parse_fuzzy_query's narrower
+        # ValueError: cjk_text isn't filtered to a guaranteed-safe token
+        # set the way the fuzzy blend's word string is, so the exact
+        # failure mode tantivy could raise here isn't pinned down.
+        logger.debug(
+            "Skipping CJK search clause: could not parse CJK text: %r",
+            cjk_text,
+        )
         return None