Skip to content

v0.23.3

ALMa v0.23.3

Patch release: a graph rebuild can no longer tell you it succeeded when it didn't, and when it does fail it says what to do about it.

Fixed

  • A rebuild that failed to store its result still reported success. The payload was computed, the write to the materialized-view table failed, the exception was logged, and the caller saw a normal return — so the job reported "Rebuilt 1 view(s)" while the stored map was unchanged, indistinguishable from a real rebuild in Activity and in the logs. The shared build helper now takes a flag: serving a cache miss still never breaks a response over a failed cache write, but a rebuild raises, because persisting is the job.

  • A rebuild where every view failed still completed. Per-view failures were caught, logged as one line without a traceback, and the run returned a normal summary with count: 0 — which reads as a successful no-op. Failures are now collected and named in the job's own result, logged at ERROR with the traceback, and a run in which nothing rebuilt and something broke fails instead of completing. A partial run still completes, with the failed views named.

  • Two diagnostics answered "healthy" when they had simply broken. The super-region "has this ever been built?" probe returned built on any exception, and the pending-work count returned nothing to repair on any exception. Both still degrade the same way — a broken probe must not drive an endless rebuild loop — but they now log the traceback, so an unreadable substrate and a healthy one are no longer the same answer.

Changed

  • Failure messages name a cause and a next step. Every graph-rebuild error now says which view failed, why (exception type and text), and what to do next — check vector coverage and run AI Compute Missing before re-running for the paper map, check author hydration for the author network, and where to find the full traceback. The reader of an Activity row has none of the context the traceback has; a cause with no remedy is a dead end.