v5.2.13

Cache source error handling

A sourcedFrom cache source that rejected with an error whose message cannot be assigned left Table.get() permanently unsettled — the request never received a response and the per-key source lock was never released. fetch with AbortSignal.timeout rejects with exactly such an error (a DOMException), so any component that put a timeout on its origin fetch turned every origin timeout into a hung request instead of an error. The settle path is now guarded end to end, including the stale-data branch that reads error.code and error.statusCode, which could hang the same way when a source rejected with a nullish value and a record was already cached. Fixes #2619.

Describe record counts

describe_table and describe_all sized a table's record count by scanning its primary store, and when that scan exceeded its time budget it fell back to a second, unbounded exact getKeysCount() over the same key space — the escape cost more than the scan it was escaping. The base count now comes from a calibrated rocksdb-js count estimator and the forward scan is bounded regardless of what the base reports. Measured on a warm page cache, the exact count took 92 ms at 1M keys and 934 ms at 10M keys, growing linearly; the estimate returns in under 0.05 ms. estimated_record_range is now derived from the evidence the samples actually provide rather than from a statistical interval around a rate the unsampled portion of the key space may not share.

Also in this release

• Cherry-pick conflict resolution for the v5.2 branch and the release version bump.

Full changelog: v5.2.12...v5.2.13