drupflare/worker - v1.0.0
    Preparing search index...

    Function streamRestoreInto

    • Applies a stored snapshot DIRECTLY into a live heap, one chunk at a time.

      Nothing larger than a single chunk is ever allocated. That is a hard requirement rather than an optimisation, and it comes from a measurement: the isolate memory ceiling is non-monotone -- a 128 MiB allocation failed while 160 MiB succeeded -- because it is an isolate-wide budget shared with whatever else a reused isolate holds. A restore that materialises the image will therefore pass N times and then fail in production, which is the worst possible test signal. The previous implementation allocated the row array, the joined buffer AND the reassembled heap: roughly 4x the image.

      Compression is absent for the same reason it was disqualified rather than traded off: DecompressionStream bills at 15.7 ms/MB of output on the edge, so inflating a 22.4 MB snapshot would cost ~350 ms of billed CPU -- 35x the free per-invocation cap -- against a memcpy measured at roughly a tenth of that. The compressed form wins on rows and storage and loses on the only meter that binds.

      Each chunk's digest is checked BEFORE its bytes are applied. A whole-image check cannot help a streaming restore: by the time it fails, the heap is already wrong.

      Parameters

      • sql: HeapSql

        The Durable Object's own SQL.

      • target: Uint8Array

        The live heap. Written in place.

      • opts: { from?: number; limit?: number; meta: SnapshotMeta; pageIndex: number[] }

        from/limit restrict the work to a slice of the chunk sequence, which is what makes a restore divisible across alarm invocations.

      Returns StreamRestoreResult