CortexDB 0.9.9
One change, and it is about telling you the truth rather than doing something new.
Readiness now reports whether the server can actually do its job.
GET /v1/admin/ready gained three checks: embeddings, enrichment and
content_processors.
Until now a server could return {"status":"healthy"} and degraded: false
while quietly underdelivering in three different ways, and nothing on the
wire distinguished that from a healthy deployment:
- A configured embedding provider whose key had stopped working.
Readiness could tell you the corpus was pinned to mock embeddings, but
not that a real provider was returning 401 on every call. New writes got
no vectors, every recall silently fell back to a degraded path, and
/v1/answerreturned nothing useful — for weeks, on a server reporting itself healthy.embeddingsis now outcome-based: it records what real provider calls actually did. - Enrichment switched off. A deployment with facts, beliefs and concepts permanently empty looked identical to one still building them. Enrichment is off by default, which makes the silence worse.
- No content processors configured. Uploads still return a
blob_id, so "stored but nothing extracted or indexed from it" was indistinguishable from success.
Three states are distinguished deliberately. unproven — booted, nothing
embedded yet — is not degraded: a server with no writes has not earned
either verdict, and a check that cries wolf gets ignored. failing means
the most recent real call failed, not "something failed once", so a
transient rate limit does not pin a deployment to degraded and a rotated key
clears it without a restart.
degraded is now true for mock or failing embeddings, and the check
carries counts, timestamps and the provider's own error text, so an
operator sees the 401 rather than inferring it.
If you run CortexDB with an external embedding provider, this is worth upgrading for: it is the difference between finding out from your monitoring and finding out from a user.
Drop-in. No API, schema or configuration changes.