Nodes/ComfyUI-ZMongo/06 Document OCR Status
ComfyUI Node

06 Document OCR Status

Check whether the server's OCR actually finished

By CentralFloridaAttorney·Created 5 months ago·Updated 2 months ago· 1
06 Document OCR Status
  • session
  • document_id_link
  • json
  • status
  • has_text
  • last_error
  • success
  • refresh
  • status_items
  • selectable_items
  • indexed_items
  • item_count
document_id
document_prefix/documents
refresh_token

"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 string
  • has_text - BOOLEAN; the real "is there recognized text to use yet" answer
  • last_error - the most recent error message, empty when nothing's gone wrong
  • success - whether the status query itself succeeded
  • json - 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.

CategoryZMongo/03 Documents

Inputs (5)

NameTypeDefaultDescription
sessionZMONGO_API_SESSION
document_idSTRING
document_prefixSTRING/documents
document_id_linkopt*
refresh_tokenoptSTRING

Outputs (10)

NameTypeDescription
jsonSTRING
statusSTRING
has_textBOOLEAN
last_errorSTRING
successBOOLEAN
refreshSTRING
status_items*
selectable_items*
indexed_itemsSTRING
item_countINT