a pod could not say why it had nowhere to send a page (v0.4.3)
A rented pod answered, for a model it was serving perfectly well over its
own loopback:
model 'datalab-to/surya-ocr-2' is not served over HTTP by this install
Not rasterisation: a PNG, which skips rasterising entirely, failed the same
way in 0.26s. The pipeline on the pod needs a LOCAL placement candidate,
where the pipeline on the orchestrator needs a POD one -- so the local path
is the one that had never run.
Two defects, and the second is why the first took all night.
1. `_model_entry_for` reads the catalogue from one place: the ConfigManager
the admin module holds. A pod has no models.json -- its catalogue is
seeded from CODERAI_SEED_MODELS into memory -- so any process or import
order where that global is not that object sees an EMPTY catalogue. The
seeded model then has no backend pin, resolves to no engine, yields no
candidate, and the pod disowns a model it is serving. It now falls back
to the seed list in the environment, which needs no global and no import
order. A real catalogue entry still wins.
2. `_local_candidate` ended in `except Exception: return None`, and
`_pod_candidate` too. Every decline now records a reason -- which of the
catalogue entry, the backend pin or the enabled flag was missing, or the
exception -- says it once, and clears it when the install starts working.
And the reason travels IN THE ERROR, not only in a log. The machine that
reads a pod's 503 is not the machine that can read its log; a pod's log is
not reachable from the orchestrator at all. Blaming configuration for what
may be a lookup, in the one sentence that does cross the network, is what
made this invisible.
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