fix: OCR escalation falls back to tier-1 result when OCR can't run

OCR is an enhancement, not a gate. Previously, escalating a scanned doc to the
OCR tier returned the OCR result unconditionally -- so with DOCUMENT_OCR_ENABLED
=true but no backend configured (no gateway URL / no MISTRAL_API_KEY) the OCR
processor returned success=False and the whole document was marked failed and
skipped: strictly worse than leaving OCR off (where it would at least index the
tier-1 text).

Now the registry keeps the tier-1 fast result when the OCR escalation doesn't
succeed (no backend, API down, empty output), logging a warning. A
misconfiguration degrades gracefully instead of dropping scanned docs.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Chris Coutinho
2026-06-05 01:49:52 +02:00
co-authored by Claude Opus 4.8
parent 3bd1b46d9c
commit 4dbf362261
2 changed files with 28 additions and 1 deletions
@@ -264,7 +264,7 @@ class ProcessorRegistry:
filename or "<bytes>",
reason,
)
return await self._run_processor(
ocr_result = await self._run_processor(
ocr,
content,
content_type,
@@ -273,6 +273,19 @@ class ProcessorRegistry:
progress_callback,
escalated=True,
)
# OCR is an enhancement, not a gate: if it can't run (no backend
# configured / API down) or returns nothing, keep the tier-1
# result rather than failing the document. Otherwise an operator
# who sets DOCUMENT_OCR_ENABLED=true without credentials would
# make scanned docs fail entirely -- strictly worse than off.
if ocr_result.success:
return ocr_result
logger.warning(
"OCR escalation did not succeed for %s (%s); keeping the "
"tier-1 result",
filename or "<bytes>",
ocr_result.metadata.get("parse_failed_reason", "error"),
)
return result