06 Document OCR Status
Check whether the server's OCR actually finished
- session
- document_id_link
- json
- status
- has_text
- last_error
- success
- refresh
- status_items
- selectable_items
- indexed_items
- item_count
"06 Queue Document OCR" schedules the job. This is the node that tells you whether the job has actually finished. "06 Document OCR Status" queries the backend for one document's OCR state and reports where it is: queued, running, done, or failed - plus whether text exists and what the last error was. If you're building an automated scan-to-text pipeline, this is the node that lets the graph wait gracefully instead of guessing.
How it works
It GETs /api/ocr/status/{document_id} and pulls the server's tracking state. The outputs are refreshingly boring, which is what you want from a status check:
status- the current OCR state as a stringhas_text- BOOLEAN; the real "is there recognized text to use yet" answerlast_error- the most recent error message, empty when nothing's gone wrongsuccess- whether the status query itself succeededjson- the full payload if you need details, plus the standard selectable tail
The useful pattern: queue OCR, then loop on this node until has_text goes true (or last_error fills in). In a plain ComfyUI graph you typically wire the status/has_text outputs into a switch or check that gates the downstream "Get Document Text" node, so the pipeline doesn't try to read text that doesn't exist yet.
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
Same hosted-only caveat as the Queue node: OCR is server-side, and the /api/ocr/status route lives on the hosted ZMongo backend. In Local File Store mode there's nothing to poll - status queries will fail rather than return "not running." Pair this with a hosted session or don't bother.
Second, has_text and success are different questions. success: true means the status query worked - the backend answered - not that OCR succeeded. has_text is the one that means "there's recognized text." Beginners conflate them and then wonder why a "successful" status check is followed by an empty text fetch.
Third, last_error is your debug port. OCR failing (a corrupt upload, a document without proper bytes) almost always leaves a message here - read it before you re-queue the same job in a loop. Re-queueing a document that fails validation forever is a classic way to spin up a pile of dead jobs in the backend queue.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| session | ZMONGO_API_SESSION | — | |
| document_id | STRING | — | |
| document_prefix | STRING | /documents | — |
| document_id_linkopt | * | — | |
| refresh_tokenopt | STRING | — |
Outputs (10)
| Name | Type | Description |
|---|---|---|
| json | STRING | — |
| status | STRING | — |
| has_text | BOOLEAN | — |
| last_error | STRING | — |
| success | BOOLEAN | — |
| refresh | STRING | — |
| status_items | * | — |
| selectable_items | * | — |
| indexed_items | STRING | — |
| item_count | INT | — |