OpenClaw 2026.10.9 Stops Large Transcript Archives from Blocking Migrations

Quick Answer

OpenClaw 2026.10.9 changes how Doctor and Gateway migration inspection and repair handle transcript archives. Instead of expanding an entire archive into one JavaScript string, the supported migration path processes JSONL records incrementally. This addresses archives whose total expanded text exceeds Node.js’s maximum string length, provided each individual record remains within that limit. The published release includes the fix; GitHub lists its release date as October 29, 2026.

The preservation rule matters as much as the parsing change: an archive that needs no record changes returns its original encoded Buffer. A changed archive receives a second decode-and-transform pass and is encoded with its original codec. These are observed implementation behaviors, described in the released stream source, rather than measured performance claims.

In Plain English

A compressed transcript can be manageable as stored bytes yet too large to represent as a single JavaScript string after decompression. PR #170853 reports an example containing 104,885,696 compressed bytes that expands to 1,020,313,060 bytes of UTF-8 JSONL. The previous migration path decompressed the archive and converted the result into one string. A valid archive could therefore block migration because of the representation chosen for inspection, rather than because its records were invalid.

The replacement reads the archive in pieces and keeps JSONL record boundaries intact across those pieces. A chunk boundary does not necessarily coincide with a complete UTF-8 character or a complete record. The released implementation accounts for both, then applies the record transformation one record at a time. It supports identity and zstd encoding, according to the versioned implementation.

This is incremental processing, but it is not a promise of constant memory use. The migration documentation still includes the stored blob, the largest record, and encoded replacement data in the memory picture. The PR also identifies source blobs held in the existing bounded batch and accumulated replacement buffers. Removing one oversized string does not remove every large allocation.

Code Evidence

The migration branch changes its unit of work

The following are exact, incomplete branch excerpts supplied by the merged patch. The leading colons belong to the surrounding branch expression; neither excerpt is a standalone function.

Before:

: transformContent(decodeSessionArchiveBytes(bytes, encoding === "zstd"), owner);

After:

: await transformArchiveBytesIncrementally({
    bytes,
    encoding,
    owner,
    signal: options?.signal,
    transformLine,
  });

The old branch passes a decoded archive to a content transformation. The new branch awaits an archive transformation with an explicit line transformer and cancellation signal. The released helper feeds input in 1 MiB chunks, preserves UTF-8 and record boundaries, and uses awaited stream pipelines.

Migration flow comparing whole-archive string decoding with incremental JSONL processing and separate unchanged and changed archive paths. — The released path checks records incrementally, preserves original bytes when unchanged, and makes a second pass when records change.

Unchanged bytes and changed records take different paths

The first pass determines whether any record changes. If none does, the helper returns the original Buffer. If a record changes, it decodes and transforms again, then re-encodes using the original codec. Both the source and documentation establish this distinction. Exact byte preservation is stronger than merely reconstructing equivalent JSONL content.

Editorial inference: keeping the original encoded Buffer may reduce unnecessary archive churn. The sources provide no measurement of storage savings or execution time. The second pass for changed archives also creates a processing tradeoff: the implementation avoids retaining rewritten content during the no-change check, but changed archives must be decoded twice. There is no supplied benchmark that quantifies that cost.

Stream completion is part of repair correctness

According to the PR and released source, awaited pipelines propagate decompression and recompression errors and settle participating streams during teardown. Cancellation preserves Doctor’s original cancellation reason. The PR records an earlier unhandled AbortError during teardown and a declaration-build implicit-any failure; follow-up changes awaited pipeline teardown and explicitly typed stream inputs.

The released regression source covers unchanged zstd byte identity, changed-record rewriting, UTF-8 and record boundaries across identity and zstd chunks, damaged zstd input, media persistence, NUL suffix handling, and blank-record rejection. The patch also includes batch coverage for cancellation during recompression and preservation of canonical bytes and retry progress. These are statements about test source and reported validation, not tests independently executed for this article.

Why It Matters

The official release notes connect this failure to large compressed conversation archives blocking Doctor migrations and preventing OpenClaw from starting. For operators encountering that specific migration path, incremental inspection removes the need to fit the whole expanded archive into one string. It does not establish that every startup failure involving an archive has the same cause.

Repair also has to preserve the authoritative data across interruption. The documentation and PR describe canonical SQLite blobs as authoritative, source verification and maintenance-authority checks before commit, bounded batches before derived-file publication, and recovery journal/cursor behavior that permits retry after publication failure. The PR says interrupted, uncommitted repairs retain canonical blobs and cursor progress for retry.

Editorial inference: successful parsing is only one part of migration correctness. Preserving the canonical source and useful retry state matters when a repair is cancelled or derived-file publication fails. That reading follows the documented recovery flow; it is not independent proof of every interruption scenario. The PR also states that configuration, schema, codec, and retention contracts do not change.

An Open Question

Should OpenClaw document and enforce a maximum individual JSONL record size, with a clear migration diagnostic for records that exceed Node’s string limit?

The PR explicitly leaves a single record beyond that limit unsupported. Incremental archive processing changes the total-archive constraint, but the largest record still matters. A documented record-size policy, an enforced check, and regression coverage showing its diagnostic would resolve this question. The supplied evidence does not establish that those additions exist.

Scope and Limitations

Release availability is supported by the 2026.10.9 release and its official notes. PR #170853 merged into main on October 13, 2026. Availability does not establish that any particular installation has upgraded or that its archive has been successfully migrated.

The PR reports 64 passing exact-head CI checks, including selected lanes with 10/10 stream tests, 16/16 archive-batch tests, and 8/8 progress tests. Those are maintainer-reported results. It states that live Gateway proof, local tests, and local typechecks were intentionally skipped under maintainer policy. No independent execution, production memory measurement, or performance benchmark is supplied for this article.

The inspection regression simulates the old decoder’s maximum-string-length RangeError by mocking that decoder. It is not a demonstrated migration against a real archive exceeding one gigabyte of expanded text. The supported conclusion is narrower: the released code changes the migration path to incremental record handling and includes targeted regression evidence. Individual oversized records, remaining buffer allocations, and the cost of decoding changed archives twice remain material limits.