From 54e22402bc6a1069f823a7a0916ed6b0277fc2ef Mon Sep 17 00:00:00 2001 From: Neil <4138956+nwparker@users.noreply.github.com> Date: Sun, 26 Jul 2026 00:52:04 -0700 Subject: [PATCH] docs(relay): trim the pending-output drain comment (#10714) Co-authored-by: Orca --- src/relay/pty-handler.ts | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/src/relay/pty-handler.ts b/src/relay/pty-handler.ts index 26dd6e085..b108d6757 100644 --- a/src/relay/pty-handler.ts +++ b/src/relay/pty-handler.ts @@ -723,11 +723,8 @@ export class PtyHandler { private flushPendingOutput(): void { this.outputFlushTimer = null - // Why: the send loop has no skip path and stops at PTY_OUTPUT_FLUSH_MAX_WRITES, so it can never - // reach a third entry — `Array.from(entries())` allocated one tuple per session every tick to - // consume at most two. Capture only that prefix, and capture it *before* the first send so a - // re-entrant sink still reads the values a whole-map snapshot would have frozen. - // Why the explicit iterator: `for...of` would advance one tuple past the limit and discard it. + // Why batch before the first send: a re-entrant sink must read the values a whole-map snapshot + // would have frozen. Why the raw iterator: `for...of` would consume one entry past the limit. const pendingEntries = this.pendingOutputByPty[Symbol.iterator]() const batch: [string, PendingPtyOutput][] = [] while (batch.length < PTY_OUTPUT_FLUSH_MAX_WRITES) {