Default PDF parser holds the whole document in memory (2 copies on the #640 recovery path); Indexer actors have no max_restarts

[andyne13]

Summary

The default PDF parser holds the entire document in memory, and on one recovery path holds two full copies at once. The Indexer actors that run it have no restart policy, so a worker that OOMs is not recovered the way Marker/Docling workers are.

This is the memory-residency half of a third-party audit finding. The admission control half is already tracked in #663 — this issue is deliberately scoped to per-file residency and worker recovery.

1. The default PDF parser is fully resident

openrag/core/indexing/parsers/pdf/pymupdf.py opens from bytes, not a path:

def _extract_markdown(raw: bytes, filename: str):
    with pymupdf.open(stream=raw, filetype="pdf") as doc:      # whole file resident
        try:
            chunks = _to_markdown(doc)
        except RuntimeError:
            cleaned = doc.tobytes(garbage=4, clean=True)       # second full copy
            with pymupdf.open(stream=cleaned, filetype="pdf") as clean_doc:
                chunks = _to_markdown(clean_doc)

raw and cleaned are both live inside the except block, so peak usage is roughly double — on the malformed-document recovery path added in #640, which is exactly where unusual (often large) documents end up.

pymupdf4llm.to_markdown(doc, page_chunks=True, ...) chunks the output per page; the document is already fully loaded by then.

This is the shipped default in all three places: conf/config.yaml:202 (pdf: PyMuPDFLoader), infra/compose/.env.example:46, and infra/charts/openrag-stack/values.yaml:666. So a default chart or compose deployment is on this path.

Marker is not affected — it splits into page ranges (marker_workers.py:293-298) and passes a path plus page_range to each worker (marker_workers.py:176-191), so its memory is bounded per batch. Anyone who has switched PDFLOADER=MarkerLoader is not exposed here.

2. Indexer actors have no restart policy

indexer_pool.py:41 and :355 declare bare @ray.remote, with no max_restarts. Marker and Docling deliberately set it:

• marker_workers.py:82 and docling_workers.py:85,97 → @ray.remote(max_restarts=5), with comments explaining that a worker which OOMs or CUDA-faults must come back.

So the tier most likely to OOM on a large PDF is the one with no recovery configured, while the GPU tiers have it.

3. .doc conversion reads the converted file whole

core/indexing/parsers/doc_parser.py:87 — return Path(out_path).read_bytes(), None after the Spire.Doc .doc → .docx conversion. Smaller in practice, but same class of issue.

Suggested direction

• Route large PDFs off the fully-resident path — either a size threshold that hands documents over a limit to Marker/Docling, or open PyMuPDF from a path so MuPDF can map rather than buffer.
• Avoid holding raw and cleaned simultaneously in the One unparseable page fails the whole document: PDF parse stage has no fallback when PyMuPDF raises (code=4: no font file for digest) #640 recovery path.
• Give the Indexer actors a max_restarts consistent with the Marker/Docling pools.
• Memory-aware admission (as opposed to count-based) belongs with No admission control / backpressure on ingestion (unbounded intake, always 201) #663.

Found by

An independent third-party audit of OpenRag; verified against v2.1.0. The audit stated this more broadly ("the indexing worker loads the complete file into memory"); narrowed here to what reproduces — most parsers do work from a path, and _sha256_file correctly streams in 1 MB chunks.

[coderabbitai]

🔗 Related PRs

#591 - fix(security): backport DoS caps + log hygiene lost in the refactor [merged]
#606 - fix(chainlit): render source PDF previews in the chat side panel [merged]
#674 - fix(marker): kill and rebuild the worker pool on parse timeout (reclaim wedged slot) [merged]
#727 - fix(indexing): recover from pymupdf font-digest errors instead of failing the file [merged]
#729 - fix(docling): make the docling pool and workers restartable (max_restarts) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!