No HTTP endpoint to check if re-indexing is in progress

[rhyswdev]

Problem

/readyz returns 200 OK throughout an active re-index because yente continues serving queries from the old index while building the new one. This means there is no HTTP endpoint to determine whether a re-index (triggered by /updatez, cron, or startup) is still in progress or has completed.

Why existing endpoints don't solve this

Endpoint	Behaviour during re-index	Why it's insufficient
GET /readyz	Returns 200 OK	Old index is healthy, so health check passes
GET /catalog	index_stale / index_current reflect the catalog version vs indexed version — not whether indexing is running	No state change if upstream data version hasn't changed (e.g. forced re-index); can't distinguish "hasn't started" from "in progress" from "finished"
POST /updatez?sync=true	Blocks until done if it acquires the lock	If another process already holds the lock, it returns 200 ok immediately (indexer.py:334-337) — a silent false "done" signal

Current workaround

Poll the lock document directly in the search backend:

GET {search_url}/{index_name}-locks/_doc/lock

This works but has drawbacks:

• Couples consumers to yente's internal search backend implementation
• The found field alone is insufficient — the lock has a 10-minute expiry (LOCK_EXPIRATION_TIME), so a stale lock from a crashed indexer shows found: true but isn't active. Callers must also check _source.acquired_at is within the expiry window.

Proposed solution

A new endpoint (e.g. GET /statusz) that exposes whether a re-index is currently in progress, so downstream systems can poll for completion without querying the search backend directly.

PR: #1085