@cloudbitmaps/core 0.5.0 → 0.6.0

package/dist/index.d.cts

@@ -61,6 +61,27 @@ interface CodecBitmap {
      * Roaring answers it in O(1) from its container index, so the flagship codec implements it.
      */
     maximum?(): number | undefined;
+    /**
+     * Re-encode for size, in place, immediately before a **cold** write. Representation only — this must never
+     * change membership, and `serialize()` afterwards must decode back to exactly the same set.
+     *
+     * **Optional, like {@link maximum}.** A codec whose encoding has no size decision to make (a plain bitset has
+     * one representation and nothing to choose) simply omits it, and the engine skips the call.
+     *
+     * WHY THIS EXISTS. Roaring picks per container between an array, a bitset and a RUN — but the run choice is
+     * not automatic in any implementation: it is a `runOptimize()` pass you have to ask for, and nothing here was
+     * asking. So two of the three container types were ever used, and run-shaped data paid list or bitmap prices
+     * for a run. Measured on the shipped codec: a contiguous 1,000,000-id range serialized to 128.1 KiB where
+     * run-encoding needs **0.2 KiB** (570×), and a 2,000-run shape 536.5 KiB against **8.5 KiB** (63×). Sparse
+     * data is unchanged, because there are no runs to find — the pass is not a gamble.
+     *
+     * WHY ONLY ON THE COLD PATH. This is called where a whole immutable generation is written, so its cost
+     * amortizes over a write that is already serializing and checksumming every chunk. It is deliberately NOT
+     * called on the warm delta path (`chunk.ts`), which runs per operation: the hot path must not pay for a
+     * rare-ish win, per KISS/YAGNI. Warm rows are short-lived and get folded into a cold generation by
+     * compaction, where they are optimized then.
+     */
+    optimize?(): void;
 }
 /**
  * A pluggable bitmap codec — the factory the codec-agnostic engine constructs {@link CodecBitmap}s through.
@@ -2021,7 +2042,15 @@ interface DestroyResult {
      * `segment.erase` audit event keys off — a cleartext "erase" is not an irreversible destruction.
      */
     readonly cryptoShredded: boolean;
-    /** `'absent'` (no registry row), `'already'` (already destroyed), or `'cleartext'` (no DEK to shred). */
+    /**
+     * Why this segment was not a fresh crypto-shred. `'absent'` (no registry row), `'already'` (already
+     * destroyed), `'cleartext'` (no DEK to shred) — and from `eraseNamespace` only, where per-segment faults are
+     * isolated so one failure cannot discard the ledger: `'contended'` (warm rows were rewritten during every
+     * erase pass) or `` `failed: <message>` `` (any other fault).
+     *
+     * The last two come with `destroyed: false` and mean **the segment still holds data**. A namespace erase
+     * returns them rather than throwing, so its entries have to be inspected — see {@link eraseNamespace}.
+     */
     readonly reason?: string;
     /** Warm rows physically deleted as part of the erase. */
     readonly warmRowsDeleted: number;

package/dist/index.d.ts

@@ -61,6 +61,27 @@ interface CodecBitmap {
      * Roaring answers it in O(1) from its container index, so the flagship codec implements it.
      */
     maximum?(): number | undefined;
+    /**
+     * Re-encode for size, in place, immediately before a **cold** write. Representation only — this must never
+     * change membership, and `serialize()` afterwards must decode back to exactly the same set.
+     *
+     * **Optional, like {@link maximum}.** A codec whose encoding has no size decision to make (a plain bitset has
+     * one representation and nothing to choose) simply omits it, and the engine skips the call.
+     *
+     * WHY THIS EXISTS. Roaring picks per container between an array, a bitset and a RUN — but the run choice is
+     * not automatic in any implementation: it is a `runOptimize()` pass you have to ask for, and nothing here was
+     * asking. So two of the three container types were ever used, and run-shaped data paid list or bitmap prices
+     * for a run. Measured on the shipped codec: a contiguous 1,000,000-id range serialized to 128.1 KiB where
+     * run-encoding needs **0.2 KiB** (570×), and a 2,000-run shape 536.5 KiB against **8.5 KiB** (63×). Sparse
+     * data is unchanged, because there are no runs to find — the pass is not a gamble.
+     *
+     * WHY ONLY ON THE COLD PATH. This is called where a whole immutable generation is written, so its cost
+     * amortizes over a write that is already serializing and checksumming every chunk. It is deliberately NOT
+     * called on the warm delta path (`chunk.ts`), which runs per operation: the hot path must not pay for a
+     * rare-ish win, per KISS/YAGNI. Warm rows are short-lived and get folded into a cold generation by
+     * compaction, where they are optimized then.
+     */
+    optimize?(): void;
 }
 /**
  * A pluggable bitmap codec — the factory the codec-agnostic engine constructs {@link CodecBitmap}s through.
@@ -2021,7 +2042,15 @@ interface DestroyResult {
      * `segment.erase` audit event keys off — a cleartext "erase" is not an irreversible destruction.
      */
     readonly cryptoShredded: boolean;
-    /** `'absent'` (no registry row), `'already'` (already destroyed), or `'cleartext'` (no DEK to shred). */
+    /**
+     * Why this segment was not a fresh crypto-shred. `'absent'` (no registry row), `'already'` (already
+     * destroyed), `'cleartext'` (no DEK to shred) — and from `eraseNamespace` only, where per-segment faults are
+     * isolated so one failure cannot discard the ledger: `'contended'` (warm rows were rewritten during every
+     * erase pass) or `` `failed: <message>` `` (any other fault).
+     *
+     * The last two come with `destroyed: false` and mean **the segment still holds data**. A namespace erase
+     * returns them rather than throwing, so its entries have to be inspected — see {@link eraseNamespace}.
+     */
     readonly reason?: string;
     /** Warm rows physically deleted as part of the erase. */
     readonly warmRowsDeleted: number;

package/dist/index.js

@@ -2074,6 +2074,7 @@ function writeCrbmGeneration(driver, key, chunks, options = {}) {
     const writer = new CrbmWriter(sink, { generation: key.generation, crypto: options.crypto });
     for (const { chunkKey, bitmap } of sorted) {
       if (bitmap.isEmpty) continue;
+      bitmap.optimize?.();
       await writer.addChunk(chunkKey, bitmap.serialize(), bitmap.size);
       const pause = tick();
       if (pause !== null) await pause;
@@ -2089,6 +2090,7 @@ async function writeCrbmGenerationStream(driver, key, chunks, options = {}) {
     const writer = new CrbmWriter(sink, { generation: key.generation, crypto: options.crypto });
     for await (const { chunkKey, bitmap } of chunks) {
       if (bitmap.isEmpty) continue;
+      bitmap.optimize?.();
       await writer.addChunk(chunkKey, bitmap.serialize(), bitmap.size);
       chunkKeys.push(chunkKey);
       cardinality += bitmap.size;
@@ -3671,7 +3673,22 @@ async function eraseNamespace(namespace, deps, options) {
   const destroyed = [];
   let segmentsShredded = 0;
   for (const ref of refs) {
-    const result = await shredSegment(ref, deps, options.allowCleartext ?? false);
+    let result;
+    try {
+      result = await shredSegment(ref, deps, options.allowCleartext ?? false);
+    } catch (err) {
+      result = {
+        segment: ref.segment,
+        namespace: ref.namespace,
+        destroyed: false,
+        cryptoShredded: false,
+        reason: isWriteConflictError(err) ? "contended" : `failed: ${err instanceof Error ? err.message : String(err)}`,
+        // Deliberately 0, and not a partial count. `eraseWarm` may have deleted rows before it threw, but the
+        // erase did not complete as a unit, so a partial figure on a failed entry would invite reading it as
+        // progress toward a destruction that did not happen. The attestation that matters is `destroyed`.
+        warmRowsDeleted: 0
+      };
+    }
     destroyed.push(result);
     if (result.cryptoShredded) {
       segmentsShredded += 1;