run-llama/liteparse · error · ParseError

{str(e)}

Error message

{str(e)}

What it means

LiteParse wraps every exception raised by the native parsing backend into a ParseError, chaining the original exception via `from e`. This means any failure during PDF loading, conversion, or extraction (corrupt files, unsupported formats, native crashes reported as errors) surfaces here as a single ParseError whose message is the native error text.

Solutions

1. Read the chained original exception (`raise ... from e`) — inspect `e.__cause__` for the native root cause
2. Verify the input file opens in a standard PDF viewer / is a supported format
3. If the document is image-only, enable OCR in the LiteParse config
4. Update the package; if reproducible with a minimal file, report the bug with the input

Example fix

// before
result = parser.parse('report.pdf')  # opaque ParseError
// after
try:
    result = parser.parse('report.pdf')
except ParseError as e:
    log.error('parse failed: %s (cause: %r)', e, e.__cause__)

from pathlib import Path
p = Path(file_data)
if not p.is_file():
    raise FileNotFoundError(p.resolve())

def is_parseable_input(data: object) -> bool:
    return isinstance(data, bytes) or (isinstance(data, (str, Path)) and Path(data).is_file())

try:
    result = parser.parse(file_data)
except ParseError as e:
    root = e.__cause__
    logger.error('parse failed: %s (cause: %r)', e, root)
    raise

When it happens

Trigger: Calling LiteParse.parse() (with a path or bytes) when the native backend fails: corrupt or encrypted PDF, unsupported/corrupt office file passed to conversion, PDFium extraction failure, or any native binding panic surfaced as a Python exception.

Common situations: Passing a file with a wrong extension that LibreOffice conversion cannot handle; parsing a scanned PDF without OCR enabled; a truncated download; memory exhaustion on very large documents.

Related errors

• parse of exceeded s; the worker process was killed
• pool_size must be >= 1
• parse_timeout must be > 0 seconds
• parser pool is closed
• parse_timeout requires pool_size

AI-assisted analysis of run-llama/liteparse@22d2dd8cd7 (2026-09-08). Data as JSON: /api/errors/0eaff8b390ce1925. Report an issue: GitHub.

Appendix: source

Thrown at packages/python/liteparse/parser.py:739

            source = f"<{len(file_data)} bytes>"
        else:
            file_path = Path(file_data)
            if not file_path.exists():
                raise FileNotFoundError(f"File not found: {file_path}")
            payload = str(file_path.absolute())
            source = payload

        if self._pool is not None:
            return self._pool.parse(payload, source)

        try:
            if isinstance(payload, bytes):
                native_result = self._native.parse_bytes(payload)
            else:
                native_result = self._native.parse(payload)
            return _convert_native_result(native_result)
        except Exception as e:
            raise ParseError(str(e)) from e

    def parse_batches(
        self,
        file_data: Union[str, Path, bytes],
        batch_size: Optional[int] = None,
    ) -> Iterator[ParseBatch]:
        """
        Parse a document in bounded-memory page batches.

        Each yielded batch is an ordinary :class:`ParseResult` covering
        ``batch.start_page`` through ``batch.end_page``, and becomes
        collectible as soon as you advance the iterator — so a loop that does
        not retain batches never holds more than one batch of pages in memory.
        A non-PDF source is converted once, not once per batch.

        Cross-page passes see only the pages in their own batch, so repeated
        header/footer removal and image deduplication are batch-local and the
        output can differ from :meth:`parse`. Prefer :meth:`parse` unless the

View on GitHub (pinned to 22d2dd8cd7)