Fixes large JSON StreamDB batches in the agents runtime/server by avoiding spread-based array appends and avoiding StreamResponse.json() for server-side JSON reads. This prevents RangeError: Maximum call stack size exceeded during wake processing and manifest rehydration, with no intended behavior change.

Root Cause

There were two variants of the same failure mode:

1. processWake accumulated live StreamDB change events with calls like:

catchUpEvents.push(...changeEvents)
deltaEvents.push(...changeEvents)

For sufficiently large live batches, spreading changeEvents passes every event as a separate function argument to push. V8 has an argument/stack limit, so a large batch can throw before the runtime finishes processing the wake.

2. StreamClient.readJson delegated to @durable-streams/client's StreamResponse.json(). That dependency currently flattens parsed JSON arrays internally with the same spread pattern, so large streams can also fail during server rehydration paths such as future-send/cron manifest loading:

RangeError: Maximum call stack size exceeded
    at StreamResponseImpl.json (.../@durable-streams/client/dist/index.js:1904:11)
    at async StreamClient.readJson (.../packages/agents-server/src/stream-client.ts:407:12)

Approach

For runtime live-batch accumulation, add a small appendAll helper that appends items with a loop instead of argument spreading:

function appendAll<T>(target: Array<T>, items: Array<T>): void {
  for (const item of items) {
    target.push(item)
  }
}

For server JSON reads, have StreamClient.readJson consume response.jsonStream() and collect items one-by-one instead of calling response.json():

const items: Array<T> = []
for await (const item of response.jsonStream()) {
  items.push(item)
}
return items

This keeps the fix local while avoiding the dependency's large-array spread path.

Key Invariants

• Batch ordering is preserved exactly: items are appended/read in source order.
• Wake offset / ack offset behavior is unchanged.
• Stream read options are unchanged: non-live reads still start from the same offset.
• Large batches no longer depend on JavaScript function-argument limits.

Non-goals

• This does not change StreamDB batching semantics.
• This does not add chunking, backpressure, or batching thresholds.
• This does not alter wake selection, freshness detection, ack behavior, or manifest schema.
• This does not patch @durable-streams/client; it avoids the problematic API at the agents-server call site.

Trade-offs

The loop/streaming code is slightly more verbose than push(...items) or response.json(), but it is safe for arbitrary batch sizes and avoids known large-array spread failure modes. A dependency-level fix would be broader, but this PR keeps the immediate agents runtime/server fix small and easy to review.

Verification

pnpm install
pnpm --filter @electric-ax/agents-runtime exec vitest run test/process-wake.test.ts --reporter=dot
pnpm --filter @electric-ax/agents-server exec vitest run test/stream-client.test.ts --reporter=dot
GITHUB_BASE_REF=main node scripts/check-changeset.mjs

Results:

packages/agents-runtime/test/process-wake.test.ts: passed
packages/agents-server/test/stream-client.test.ts: 10 passed
Changesets cover affected packages

Also ran:

pnpm --filter @electric-ax/agents-server typecheck

That still fails on existing local workspace resolution/type issues around @electric-sql/client and related implicit-any errors, but the new stream-client.ts type error found during iteration was fixed.

Files changed

• packages/agents-runtime/src/process-wake.ts — replaces spread-based live-batch appends with appendAll.
• packages/agents-server/src/stream-client.ts — changes readJson to consume jsonStream() one item at a time instead of response.json().
• packages/agents-server/test/stream-client.test.ts — adds a regression test ensuring large reads do not call StreamResponse.json().
• .changeset/large-live-batches.md — adds patch changesets for @electric-ax/agents-runtime and @electric-ax/agents-server.