06 Queue Document OCR

Ingest extracts text from PDFs, but only when the PDF has text. The moment you hand it a scanned, image-only document it shrugs and says "use OCR." This node is that OCR. "06 Queue Document OCR" submits a document to the backend's OCR queue - you tell it which document and how urgent, and the server handles the recognition asynchronously. It's the "drop this in the inbox" half of the pair; "06 Document OCR Status" is the "did it get done yet?" half.

How it works

It POSTs /api/ocr/queue/{document_id} with a priority (0–100, default 50) and a source tag (default comfyui_zmongo_document_node) that records where the job came from. The document must already exist and carry the file bytes for OCR to work on - which is exactly why this node pairs with "06 Upload Document File": Upload stores the raw PDF, then Queue OCR tells the server to read it. It returns the document_id, a status string (the initial queue state), and success.

The key word is queue. This is asynchronous server-side work, not a blocking call. When the node returns, OCR hasn't happened yet - it's been scheduled. How long it takes depends on the backend's queue and the document size. So don't wire this straight into a node expecting text; poll with the status node (or check status output) and fetch text once it reports done.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/CentralFloridaAttorney/ComfyUI-ZMongo

Restart ComfyUI, or install "ComfyUI-ZMongo" via ComfyUI Manager.

Where people get burned

The big one: this is a hosted-backend feature. OCR runs on the server, and the /api/ocr/queue route lives on the hosted ZMongo/BPA backend - there's no local OCR engine in this pack, and Local File Store sessions don't implement this route. If you're entirely local, this node will fail (or have nothing to submit to). The README's architecture makes the same point: server-side OCR is part of the "hosted production cluster" story, not the zero-config local path. For local scanned PDFs you're looking at a different OCR tool entirely.

Second, priority isn't a "make it faster" slider you can abuse. It's a scheduling hint for the backend queue; the exact effect depends on the server. Set it 0–100 and move on.

Third, sequencing: don't queue OCR before the document exists with its file bytes. If document_id points at an empty record or one created without the binary payload, the job either fails or produces nothing - the status output and the Status node will tell you. And remember it's fire-and-forget: after success: true, the real work is still ahead of it in the queue. Wire up the status poll, don't sit there refreshing.