v5.1.24
Storage engine
Fixes silent missing or wrong rows on multi-table requests. Bumps @harperfast/rocksdb-js to 2.4.1, which carries the cross-column-family transactional read fix (rocksdb-js #717, backported to the 2.4 line in #732).
TransactionHandle::get honored the caller's column-family override on its synchronous block-cache-tier attempt but dropped it in the async worker, falling back to the transaction's own column family. Because all tables in a Harper database share one read transaction, every table after the first in a given request was read through a foreign column family. Reads that hit the block cache were correct; reads that missed it silently returned not-found — so the failure was intermittent and scaled with cache residency. A warm key set read correctly, a cold one lost most or all of its records, and the symptom was worst immediately after a restart and healed as traffic warmed the cache. Where two tables share a key format, a read could also hit in the foreign column family and return another table's row.
This is the defect behind #1881 (secondary-index reads returning partial or empty results for the second table accessed in a request).
Any deployment on rocksdb-js 2.4.0 is affected regardless of whether it currently looks healthy — steady traffic keeps keys warm and masks it. The dependency floor is now pinned so the fix cannot be lost to dependency resolution at image-build time; previously the range permitted a fixed version but the lockfile did not require one, so what shipped depended on when the image was built.
Security
Table read permissions are now enforced for subscriptions (#1914). Tables using loadAsInstance = false did not invoke allowRead before subscription setup, so a checked subscription could bypass table read permissions that the equivalent get would have enforced. Subscription setup now matches the get authorization contract.
This preserves v5.1's table-level permission semantics rather than backporting main's row-level delivery behavior.
Also in this release
CI: synced the claude-review.yml caller with main on the release branch.
Not in this release, despite appearing in the commit list: "fix(query): stop query planning from mutating the caller's conditions" (#1911) was cherry-picked onto the release branch and then reverted before the cut. Its commits and the revert both show up in the raw changelog below and cancel out — there is no query-planning behavior change in 5.1.24. That fix remains on main for 5.2.
Full Changelog: v5.1.23...v5.1.24