function extractData(frame: string) { return frame .split(/\...

Prompt

function extractData(frame: string) { return frame .split(/\r?\n/) .filter((line) => line.startsWith("data:")) .map((line) => line.slice(5).trimStart()) .join("\n"); } export async function* readSseData(body: ReadableStream<Uint8Array>) { const reader = body.getReader(); const decoder = new TextDecoder(); let buffer = ""; try { while (true) { const { value, done } = await reader.read(); buffer += done ? decoder.decode() : decoder.decode(value, { stream: true }); let match: RegExpExecArray | null; while ((match = /\r?\n\r?\n/.exec(buffer))) { const frame = buffer.slice(0, match.index); buffer = buffer.slice(match.index + match[0].length); const data = extractData(frame); if (data) yield data; } if (done) { const data = extractData(buffer); if (data) yield data; break; } } } finally { await reader.cancel().catch(() => undefined); reader.releaseLock(); } } 1. [line 3 / .split(/\r?\n/)] — Logic error: valid SSE lines terminated by a lone \r are not split into separate lines. 2. [line 4 / .startsWith("data:")] — Logic error: valid colonless SSE data lines are ignored. 3. [line 5 / .trimStart()] — Logic error: data values beginning with multiple ASCII spaces are corrupted because all leading spaces are removed instead of only the single optional space after the colon. 4. [line 5 / .trimStart()] — Logic error: data values beginning with tabs or other Unicode whitespace are corrupted because SSE does not strip those characters. 5. [line 18 / /\r?\n\r?\n/] — Logic error: valid SSE event separators using lone-\r line endings are not detected. 6. [line 18 / .exec(buffer)] — Performance error: when no separator is present, the full accumulated buffer is rescanned after every chunk, causing quadratic-time behavior for large incomplete events. 7. [line 16 / buffer += ...] — Runtime/performance error: buffer grows without a size bound when no event separator arrives, so large or unterminated events can exhaust memory. 8. [line 22 / if (data) yield data;] — Logic error: completed SSE events whose data payload is the empty string are dropped. 9. [lines 24-26 / EOF flush] — Logic error: buffered data is emitted at end-of-stream even when the final SSE event was not terminated by a blank line. 10. [line 15 with lines 30-32 / pending reader.read() cleanup] — Runtime cleanup error: if iterator cancellation occurs while reader.read() is pending, the finally cleanup is not reached until the read settles, leaving a stalled stream locked. 1. [line 3 / split] — logic: /\r?\n/ does not split on a lone CR, so CR-delimited SSE lines stay one string, a CR can remain in the value, and a following field can be left as \rdata:.... 2. [line 4 / startsWith("data:")] — logic: a line whose field name is exactly data with no colon is a valid empty data field and is ignored, so multiline data loses that field and its required LF. 3. [line 5 / trimStart] — logic: SSE removes at most one leading U+0020; trimStart() removes every leading whitespace character, changing the payload, and a value reduced to "" is then dropped by if (data) on lines 22 and 26. 4. [line 16 / buffer append] — logic: a leading UTF-8 BOM is decoded to U+FEFF and never stripped, so the first line fails the data: test and that field is dropped. 5. [line 18 / /\r?\n\r?\n/] — logic: a blank line ended by a lone CR (\r\r or \n\r) is not a match, so those events are not split and later fields can be merged or dropped. 6. [line 32 / reader.releaseLock] — runtime: reader.cancel() on line 31 already releases the reader, so releaseLock() throws TypeError on success, read failure, and early return, failing the generator and masking any earlier error. 1. [L3 .split(/\r?\n/)] — Logic: a lone CR is not treated as a line terminator (SSE allows CR, LF, CRLF), so CR-terminated lines are not separated and the \r is carried into the yielded data (e.g. data: a\r\r\n\r\n yields "a\r" instead of "a"). 2. [L4 line.startsWith("data:")] — Logic: a bare data line (field with no colon, which the SSE spec treats as data with an empty value) is silently ignored instead of contributing an empty line to the event data. 3. [L5 .trimStart()] — Logic: strips all leading whitespace (multiple spaces, tabs, NBSP, BOM, CR, …) instead of exactly one optional leading U+0020 as the SSE spec requires; payloads that intentionally start with whitespace are corrupted. 4. [L18 /\r?\n\r?\n/] — Logic: the frame delimiter does not recognize CR-only blank lines (\r\r, \r\r\n, \r\n\r), so a CR-delimited stream never dispatches any event, buffer grows unbounded until EOF, and everything is then emitted as one merged event. 5. [L18 /\r?\n\r?\n/.exec(buffer)] — Performance: on every incoming chunk the entire accumulated buffer is re-scanned from index 0 (no resume offset), giving O(n²) scanning for a large event spread over many chunks. 6. [L22 if (data) yield data;] — Logic/ambiguity: the truthiness check conflates "no data field present" with "data field with empty value" (data: / data: ), so events whose data is the empty string are silently dropped, contrary to the SSE spec which dispatches them. 7. [L26 if (data) yield data;] — Logic/ambiguity: same conflation for the trailing frame; an empty-data final event is dropped. 8. [L24–L26 if (done) { const data = extractData(buffer); … }] — Logic: the incomplete final frame (no terminating blank line) is yielded as if it were a complete event; the SSE spec requires pending data at EOF to be discarded, so a truncated/partial payload can be emitted as a valid event. 1. [line 3 / split(/\r?\n/)] — Protocol: Bare CR (\r) line endings inside frames are not recognized; data: a\rdata: b\n\n produces a\rdata: b instead of a\nb. 2. [line 4 / startsWith("data:")] — Protocol: Colonless data fields, which represent empty data values, are ignored; data\ndata: x\n\n produces x instead of \nx. 3. [line 5 / trimStart()] — Data corruption: Removes all leading whitespace from field values, whereas SSE removes only one optional ASCII space; significant additional spaces, tabs, and other leading whitespace are lost. 4. [lines 16–20 / buffer] — Memory: Complete comment-only keepalive lines such as : ping\n remain buffered until a blank line arrives; an ongoing stream of these lines causes unbounded memory growth despite containing no pending event data. 5. [line 18 / /\r?\n\r?\n/] — Protocol: Event boundaries containing standalone CR line endings are not recognized; a completed event such as data: x\n\r remains undispatched while the stream stays open without further input. 6. [line 18 / .exec(buffer)] — Performance: Every read searches an unfinished frame again from its beginning, causing quadratic total delimiter-scanning work when one large event arrives in many fixed-size chunks. 7. [line 22 / if (data)] — Logic: Valid events with an empty-string payload, such as data:\n\n, are discarded because an empty payload is treated as absence of a data field. 8. [lines 24–26 / EOF handling] — Protocol: Buffered data is emitted without a terminating blank line; inputs such as data: x or data: x\n incorrectly produce an event instead of discarding the unfinished final event. that's all. END OF ERROR LIST.