v5.2.5

Transactions and data integrity

• A write issued after its transaction scope had completed could be silently dropped (#2291, cherry-picked as #2307). When a table call found no live transaction on its context — including the placeholder a completed scope leaves behind — it built an ImmediateTransaction whose native handle the commit path then discarded, staged writes and all. There was no error and no log line: the caller's await resolved normally over a record that was never written. On 5.2.4 this failed Central Manager's POST /Cluster on every request. 5.1 and 5.2.0 were unaffected — the loss is latent in the commit path but only became reachable once a completed scope started leaving a released-transaction placeholder in the slot.
• Writes after an explicit mid-scope commit are atomic with the scope that owns them again (#2239). A handler that commits its own transaction mid-scope — the documented await getContext().transaction.commit() — had each subsequent write in that scope serviced and committed on its own, so a handler that failed halfway left the earlier half durable and unrollbackable. That is the mechanism behind a failed cluster delete leaving a cluster marked TERMINATED with its instances still RUNNING. A successful commit that is not the scope's final one now rotates the owning transaction to a fresh open generation. LMDB has always behaved this way; only the RocksDB path diverged, so this closes a property the 4.7 → 5.x upgrade quietly dropped rather than adding a new one.

Operations and observability

• get_status now waits for every live worker thread (#1952). Collection was sized from a logical worker count and could return before all physical threads had replied. During a rolling restart an old and a replacement thread can share a logical worker index, so one response overwrote the other and could hide an error. The collector now snapshots the eligible physical thread IDs and completes only once each has replied, keeping overlapping generations distinct internally. The response payload is unchanged — duplicate generations still collapse to the existing name@worker-N label, retaining the worst status. Worth knowing on upgrade: a routine redeploy can now surface a real transient loading or error state that the previous overwrite accidentally masked.

Vector search

• HNSW index quality scales with graph size (#2181). A fixed construction candidate list eventually stops creating enough useful edges, so recall degrades as a graph grows. efConstruction now auto-scales from a base of 100 as min(1024, 100 × sqrt(nodes / 250K)), and the search-ef ceiling resumes scaling above one million nodes, up to 2048. Graphs below 250K nodes keep the previous default, and nodes inserted before a scale threshold keep their existing edges — the ramp applies to new inserts and to a reindex. An explicit efConstruction, efConstructionSearch, or per-query ef remains an authoritative cost ceiling, so a pinned index can return fewer rows than limit unless the query supplies a larger ef.

Also in this release

• CI: the v5.2 branch now pins the same ai-review-prompts revision as main, restoring AI review coverage for PRs that target the release branch (#2308).

Full Changelog: v5.2.4...v5.2.5