chore(release): v1.2.2

[gloryfromca]

Bumps to 1.2.2 and cuts the changelog. Also carries the fix that was #385 rather than shipping this release with a known stall — that PR is closed in favour of this one.

What's in 1.2.2

The storage-layer reliability work from #379 and #384, plus one fix found after #384 merged.

The headline fix. Index maintenance bundled compaction and version cleanup into one commit, and under sustained writes that commit kept being preempted — a soak run measured 16 successes against 547 conflicts over 21 hours while the index directory grew to the disk guardrail. Compaction is now lock-free and reclamation runs under the per-table write lock, so it completes on every beat.

Everything else, in one line each:

• Every write-lock critical section is bounded by a deadline that covers acquisition as well as the body, so no path can wait for the lock or hold it indefinitely. Budgets come from measurements (row writes are 2–25ms → 15s; rebuild → 300s; prune → 60s), because the budget doubles as how long a wedged table stays invisible.
• GET /health grew a cascade readiness block. Alert on cascade.healthy — it flips false only on operational faults, names the affected table in reasons, and deliberately ignores the data-quality backlog (failed_permanent) so the signal does not sit red until a human edits markdown.
• everos cascade rebuild recovers a drifted or corrupt index from markdown. It refuses to run while a server holds the OME lock (exit 3) — the one operator-visible behaviour change in this release; scripted callers must stop the server first.
• Startup now detects column type drift, not just missing/extra columns, and points at cascade rebuild instead of "delete the index directory" (which leaves the queue marked done and the index empty).
• A query vector whose width disagrees with the provider's declared dim fails immediately with CONFIGURATION_ERROR instead of 13–14s and an unhandled 500.
• Benign commit conflicts no longer count as failures, so cascade_lancedb_optimize_failed alert volume drops and spurious fallback index rebuilds stop.
• Exception logging no longer renders frame locals: one exception went from 6423 log lines to 103, and request payloads stop leaking into logs.

The #385 fix, and why it belongs here

After #384 merged, a 1h high-rate run reproduced the stall it was supposed to close, on a different table: episode went 13 minutes without a reclaim — retained versions climbing 63 → 71 — while the other two collapsed to 1, with zero failure logs.

The deadline covered the critical section but not the await ahead of it (table = await self._table()). A hang there never returns, and the scheduler skips a kind whose task is still in flight, so that table stopped being maintained permanently and silently. Handle resolution moved inside the deadline for all seven locked operations, the lock-free compaction beat got its own deadline, and the scheduler adds a last-resort 180s bound on the whole call.

Worth noting the per-kind staleness alert shipping in this same release is what surfaced it — it went healthy=false naming episode once staleness crossed 900s. The previous signal took the newest reclaim across tables, so two healthy tables hid the dead one.

Release mechanics

pyproject.toml, uv.lock, docs/openapi.json (version string only — no schema change), CHANGELOG.md cut as [1.2.2] - 2026-08-04. everos.__version__ verified at 1.2.2.

Verification

make lint clean (ruff, import-linter 3/3, datetime discipline, openapi --check), 1896 unit + 182 integration passing.

Nine soak / concurrency / fault-injection runs, ~120 hours total. The last three at 2.5x write rate with a second process running cascade sync every second and doubled fuzz:

• disk bounded and fully reclaimed (3489MB peak → 644MB floor, then flat);
• cross-process integrity CLEAN — no schema drift, markdown↔index counts consistent;
• 0 crashes / 0 OOM / 0 restarts;
• write-lock deadline warnings at 2 per 9416 writes, both auto-retried, zero permanent failures from them.

Runs 7–9 each found a real defect, all fixed in this release. Details per run are in Confluence under the LanceDB folder.

🤖 Generated with Claude Code