🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo 'Files:'
git ls-files | rg '(^|/)src/response\.ts$' || true

echo
echo 'Relevant src/response.ts section:'
if [ -f src/response.ts ]; then
  nl -ba src/response.ts | sed -n '180,240p'
fi

echo
echo 'Search primeStream usages:'
rg -n "primeStream|void reader\.cancel|reader\.cancel\(|ReadableStream|ReadableStreamDefaultReader" src || true

Repository: h3js/h3

Length of output: 244

🌐 Web query:

WHATWG Streams tee cancellation propagate cancellation reason from one branch to the other ReadableStreamDefaultReader cancel promise rejects

💡 Result:

In the WHATWG Streams API, teeing a ReadableStream creates two independent branches [1][2]. Cancellation of the original stream is only propagated to the underlying source once both branches have been canceled [1]. Specifically, the behavior regarding cancellation and promise resolution is as follows: 1. Cancellation Propagation: When you cancel one branch, it does not immediately trigger cancellation of the underlying stream [1]. The underlying stream is only canceled after both branches have been canceled [1]. At that point, a composite cancellation reason (typically an array containing the reasons from both branches) is propagated to the original stream's underlying source [1][3]. 2. ReadableStreamDefaultReader cancel Promise: The promise returned by a branch's reader.cancel method remains pending until that specific branch is considered "canceled" within the context of the tee [1]. Historically, there have been edge cases where these promises would not resolve if the other branch continued to read until completion (the end of the stream), though specification updates have addressed these synchronization issues to ensure proper resolution [4][5]. If you are experiencing a situation where a cancel promise is rejecting or failing to resolve, it is typically because the tee logic requires both branches to reach a finalized state (either canceled or fully consumed/closed) before the internal cancellation of the original stream is finalized and the promises are settled [1][4]. Individual reader cancellation promises are tied to the state of their respective branches and the overall synchronization state of the tee operation [1][3].

Citations:

• 1: https://streams.spec.whatwg.org/
• 2: https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream/tee
• 3: nodejs/node@6ed3367155
• 4: Cancelling one branch of a tee'd stream never finishes if other branch reads all chunks whatwg/streams#1038
• 5: Fix cancelPromise in ReadableStreamTee being resolved twice  whatwg/streams#1112

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo 'Relevant src/response.ts section:'
python3 - <<'PY'
from pathlib import Path
p = Path('src/response.ts')
for i, line in enumerate(p.read_text().splitlines(), 1):
    if 180 <= i <= 240:
        print(f'{i:4d}\t{line}')
PY

echo
echo 'Search primeStream usages:'
rg -n "primeStream|void reader\.cancel|reader\.cancel\(|ReadableStream|ReadableStreamDefaultReader" src || true

Repository: h3js/h3

Length of output: 3699

🌐 Web query:

Node.js ReadableStream cancel() promise rejects underlying source cancel rejection streams

💡 Result:

When you call the cancel method on a ReadableStream (or its reader), the behavior regarding the underlying source's cancel rejection is as follows: According to the Streams Standard, if the underlying source's cancel method returns a rejected promise (or throws an exception), the promise returned by the consumer's readableStream.cancel call will also reject with that same error [1][2]. However, regardless of whether the cancellation process succeeds or fails, the stream itself is transitioned to a "closed" state rather than an "errored" state [1][2]. This design choice reflects that once a consumer has signaled a loss of interest in a stream by calling cancel, a subsequent failure in the cancellation cleanup mechanism does not impact the consumer's view of the stream as having been successfully discarded [1][2]. In Node.js, this behavior is consistently implemented; even if the underlying source's cancel rejection occurs, the stream is put into a closed state, and the failure is communicated solely through the rejection of the promise returned by the cancel call [3].

Citations:

• 1: https://streams.spec.whatwg.org/
• 2: https://streams.spec.whatwg.org/review-drafts/2024-08/
• 3: ReadableStream.cancel doesn't conform to spec nodejs/node#41048

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.