a pod that cannot run the pipeline is not a failed page (v0.4.2)
0.4.1 sent pages to the pods, as it was meant to. The pods answered 503:
model 'datalab-to/surya-ocr-2' is not served over HTTP by this
install, so an OCR engine cannot attach to it
_read_on_pods raised that, so the document failed -- while the local
pipeline sat there perfectly able to read it. The method's own docstring
already said "an optimisation that cannot run must cost latency, never an
error"; only the "no pod at all" case implemented it.
A refusal (404/501/503 from the pod's own /v1/ocr) is now a fallback, not a
failure:
* the rest of the document stops being sent one failure at a time;
* the pool is set aside for 300s, so the next document does not pay a
failed round trip per page, and a rebuilt image is picked up without
restarting the orchestrator;
* it is said ONCE, in the pod's own words, and says that this box will now
rasterise so its memory is worth watching.
A 400 still fails: falling back on any error would hide a broken page
behind a slow one.
This restores service. It does NOT make the pods run the pipeline -- that
is the next commit, and the log line above is what will say when it works.
Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KnfkxBpcZ1v6ypRFFyhrVM
Showing
Please
register
or
sign in
to comment