fix(logs): prevent stack overflow flushing large DuckDB write buffers

[grahaml]

Problem

DuckDBStorage.flushWriteBuffer() flushes the entire write buffer in a single INSERT, and on failure requeues it with unshift(...toFlush). Both spread a potentially huge array as function arguments:

• the INSERT builds one statement with ~7 bound params per row, spread into db.run(sql, ...params), and
• the failure path spreads the whole batch into Array.prototype.unshift.

Once the buffer grows past V8's argument limit (~100k elements), this throws RangeError: Maximum call stack size exceeded. That error masks the original write failure, and because clear() calls flushWriteBuffer() before its DELETE, a wedged flush can stop the table from ever draining — so the buffer/table keeps growing.

Observed in production as a steady stream of DuckDB flush error: RangeError: Maximum call stack size exceeded, alongside Parquet-export OOMs on the same oversized tables.

Fix

• Chunked inserts — writeBatchInternal now inserts in fixed-size chunks (WRITE_CHUNK_SIZE = 1000) via a new writeChunk helper, instead of one statement spanning the whole buffer. Each statement is bounded regardless of buffer size.
• Safe requeue — on flush failure, requeue with this.writeBuffer = toFlush.concat(this.writeBuffer) instead of unshift(...toFlush), so requeue can't overflow the stack and the original error surfaces.

No behavior change on the happy path; purely bounds the per-statement size and makes the failure path safe.

Testing

Type-checks clean (tsc --noEmit, 0 errors). The fix is localized to duckdb-storage.ts.

🤖 Generated with Claude Code