fix(cli-kit): batch large output chunks to prevent event loop blocking

[alfonso-noriega]

Problem

When a POS UI extension throws a large stack trace, the entire output arrives as a single write() call to ConcurrentOutput's Writable stream. The synchronous processing of large chunks — stripAnsi(), split(/\n/), and setProcessOutput with a spread of the full accumulated array — causes a render cycle expensive enough to block the Node.js event loop. During that time, Ink's useInput hook cannot process keypresses, so q (quit) and p (preview) become unresponsive.

Fix

The writableStream write handler now uses a two-stage pipeline: a Transform stream that splits large chunks into batches of MAX_LINES_PER_BATCH (20) lines, followed by a Writable sink that renders each batch. For batches from large chunks, setImmediate(next) yields to the event loop between renders so Ink's input handling can run.

• Chunks ≤ 20 lines: unchanged behavior, next() called synchronously
• Chunks > 20 lines: split into 20-line batches with setImmediate scheduling between each batch

The Transform stream preserves the existing outputContextStore context (prefix and stripAnsi overrides) and maintains proper Node.js backpressure by deferring next() until each batch is processed.

Test

Added a test that writes 250 lines as a single chunk and verifies all lines appear in the rendered output without being dropped during batch processing.

[github-actions]

Coverage report

St.❔	Category	Percentage	Covered / Total
🟡	Statements	77.25%	14578/18871
🟡	Branches	70.88%	7230/10200
🟡	Functions	76.22%	3702/4857
🟡	Lines	78.74%	13779/17500

Test suite run success

3807 tests passing in 1462 suites.

Report generated by 🧪jest coverage report action from 1afb5c2

[alfonso-noriega]

• fix(cli-kit): batch large output chunks to prevent event loop blocking #7008 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

We detected some changes at packages/*/src and there are no updates in the .changeset.
If the changes are user-facing, run pnpm changeset add to track your changes and include them in the next release CHANGELOG.

Caution

DO NOT create changesets for features which you do not wish to be included in the public changelog of the next CLI release.

[ryancbahan]

nice job! the current approach is in the right direction, but using setImmediate with recursion isn't going to give you backpressure (something node is good at managing), it's just spreading work across event loop ticks. i'm, pretty sure you can leverage node's streaming to split work + auto-support backpressure with something like this:

 const splitter = new Transform({
    transform(chunk, _encoding, callback) {
      const lines = chunk.toString('utf8').replace(/\n$/, '').split('\n')
      for (let i = 0; i < lines.length; i += MAX_LINES_PER_BATCH) {
        this.push(lines.slice(i, i + MAX_LINES_PER_BATCH).join('\n'))
      }
      callback()
    },
  })

  const writable = new Writable({
    write(chunk, _encoding, next) {
      // existing logic, unchanged — always gets small chunks now
      const log = chunk.toString('utf8')
      // ...
      next()
    },
  })

  splitter.pipe(writable)
  // hand `splitter` to the process as its stdout/stderr

that way, when writer hasn't called next() yet, the internal buffer fills up, and node automatically pauses the producer. that will allow us to be a bit more blind to the chunking management in the main flow and allow node to stream accordingly to the local machine's memory limits.