ReadableStream cancellation is a consumer decision to stop receiving data. A producer-reported error is a source failure. Cancellation closes the consumer-facing stream even if underlying cleanup rejects, while an error stores the failure and makes pending or later reads reject. The same absence of future chunks can therefore come from sharply different causes and evidence.
This specialist guide belongs to the Websites root. It also connects to The Gold Standard of Education | Learning That Transfers into Life and the How X Works hub. The worked cases are original teaching examples; their values and event logs are stated so each conclusion can be checked.
eduKateSG · Websites
Find your next learning step
Use matched streams with a logged cancel callback and a named producer error. Queue the same prefix, then either cancel or call controller.error. Compare queue fate, pending reads, reader.closed, cleanup reasons and the promise returned by cancel. The later chapters cover locked streams, reader.cancel, cleanup rejection and responsible application reporting.
ROUTE 1 · CHAPTERS 1–3
Build the first model
Name the input, state, conversion or predicate before following user-visible results.
ROUTE 2 · CHAPTERS 4–5
Trace the decisive branch
Work the accepted path and the nearest boundary case with original examples.
ROUTE 3 · CHAPTERS 6–8
Change one premise
Rebuild the mechanism when state, value, realm, timing or object kind changes.
ROUTE 4 · CHAPTERS 9–10
Handle limits and failures
Keep abrupt completion, availability and application limits visible.
ROUTE 5 · CHAPTERS 11–12
Verify and explain
Use a decisive fixture, changed-context check and concise final account.
Chapter contents
Build the first model · Chapters 1–3
1. Name who initiated termination
Trace the decisive branch · Chapters 4–5
Change one premise · Chapters 6–8
6. Handle a rejecting cancel algorithm
Handle limits and failures · Chapters 9–10
Verify and explain · Chapters 11–12
The short answer is that cancellation begins with a consumer or pipe expressing disinterest, while controller.error begins with the producer reporting that the source cannot continue correctly. Chapter 1 focuses on name who initiated termination. Begin with keep initiator, reason, queue fate, cancel-algorithm promise, stored stream error, pending reads and reader.closed outcome in separate columns. Writing those facts first prevents a familiar label or final summary value from replacing the mechanism or measurement basis that actually decides the result.
Worked example. create identical streams, call reader.cancel(‘unused’) on one and controller.error(E) on the other, then label the first actor in each trace. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the operation, then record each conversion, selection, calculation, check or state transition in order. If a prerequisite fails, stop the trace there rather than inferring later effects from the usual path.
A useful first-principles question for name who initiated termination is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. trigger cancellation through pipeTo after a destination failure; the consumer-side cause now comes from piping rather than direct reader code. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: the reason value can look similar in logs, so initiator and operation name must remain explicit. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. record call site, exact reason identity and the first state-changing algorithm. Capture the reported values and failure conditions, but also preserve the calculation or event trail that led to them. A check that asserts only the last number or label can pass even when an earlier selection, conversion, grouping, state change or measurement basis was wrong.
A concise final explanation of name who initiated termination should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, one software message or an unstated assumption. That form is short enough for revision and precise enough for a reproducible technical note.
CHAPTER 2 OF 12 · Build the first model
2. Follow cancellation to a closed consumer view
The short answer is that cancel resets the queue, closes the readable stream and runs the underlying cancel algorithm with the supplied reason. Chapter 2 focuses on follow cancellation to a closed consumer view. Begin with keep initiator, reason, queue fate, cancel-algorithm promise, stored stream error, pending reads and reader.closed outcome in separate columns. Writing those facts first prevents a familiar label or final summary value from replacing the mechanism or measurement basis that actually decides the result.
Worked example. queue A and B, cancel with R before reading and verify no chunk is delivered while cancel(R) is logged. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the operation, then record each conversion, selection, calculation, check or state transition in order. If a prerequisite fails, stop the trace there rather than inferring later effects from the usual path.
A useful first-principles question for follow cancellation to a closed consumer view is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. read A first, then cancel; A remains observed and B is discarded. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: a fulfilled cancel promise reports cleanup completion, not successful processing of discarded chunks. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. assert queue disposal, cancel callback reason, cancel promise and reader.closed fulfillment. Capture the reported values and failure conditions, but also preserve the calculation or event trail that led to them. A check that asserts only the last number or label can pass even when an earlier selection, conversion, grouping, state change or measurement basis was wrong.
A concise final explanation of follow cancellation to a closed consumer view should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, one software message or an unstated assumption. That form is short enough for revision and precise enough for a reproducible technical note.
The short answer is that controller.error stores the error, clears the queue and makes pending or later reads reject with that error. Chapter 3 focuses on follow producer error to rejected reads. Begin with keep initiator, reason, queue fate, cancel-algorithm promise, stored stream error, pending reads and reader.closed outcome in separate columns. Writing those facts first prevents a familiar label or final summary value from replacing the mechanism or measurement basis that actually decides the result.
Worked example. queue A and B, call error(E), then capture read and reader.closed rejections with E. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the operation, then record each conversion, selection, calculation, check or state transition in order. If a prerequisite fails, stop the trace there rather than inferring later effects from the usual path.
A useful first-principles question for follow producer error to rejected reads is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. deliver A first and error afterward; the observed prefix remains but B is not delivered. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: an error is not converted to orderly done true merely because some earlier reads succeeded. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. assert exact stored-error identity across pending read and reader.closed rejections. Capture the reported values and failure conditions, but also preserve the calculation or event trail that led to them. A check that asserts only the last number or label can pass even when an earlier selection, conversion, grouping, state change or measurement basis was wrong.
A concise final explanation of follow producer error to rejected reads should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, one software message or an unstated assumption. That form is short enough for revision and precise enough for a reproducible technical note.
The short answer is that a pending read fulfills with done true on cancellation-driven closure but rejects on producer error. Chapter 4 focuses on compare pending read settlement. Begin with keep initiator, reason, queue fate, cancel-algorithm promise, stored stream error, pending reads and reader.closed outcome in separate columns. Writing those facts first prevents a familiar label or final summary value from replacing the mechanism or measurement basis that actually decides the result.
Worked example. start read P on an empty stream, cancel in one fixture and error in another, then compare P. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the operation, then record each conversion, selection, calculation, check or state transition in order. If a prerequisite fails, stop the trace there rather than inferring later effects from the usual path.
A useful first-principles question for compare pending read settlement is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. enqueue A before the terminal action; P can fulfill A before either terminal path affects the next read. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: one settled read cannot describe the stream’s complete terminal cause. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. number pending and later reads and capture value, done and rejection separately. Capture the reported values and failure conditions, but also preserve the calculation or event trail that led to them. A check that asserts only the last number or label can pass even when an earlier selection, conversion, grouping, state change or measurement basis was wrong.
A concise final explanation of compare pending read settlement should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, one software message or an unstated assumption. That form is short enough for revision and precise enough for a reproducible technical note.
CHAPTER 5 OF 12 · Trace the decisive branch
5. Separate cancellation reason from stored error
The short answer is that the cancellation reason is passed to underlying cleanup, but the consumer-facing stream closes rather than storing that reason as a stream error. Chapter 5 focuses on separate cancellation reason from stored error. Begin with keep initiator, reason, queue fate, cancel-algorithm promise, stored stream error, pending reads and reader.closed outcome in separate columns. Writing those facts first prevents a familiar label or final summary value from replacing the mechanism or measurement basis that actually decides the result.
Worked example. cancel with object R, then show reader.closed fulfills while the underlying cancel callback received R. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the operation, then record each conversion, selection, calculation, check or state transition in order. If a prerequisite fails, stop the trace there rather than inferring later effects from the usual path.
A useful first-principles question for separate cancellation reason from stored error is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. use the same object R in controller.error; reader.closed now rejects with R. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: sharing a reason object does not make cancel and error semantically equivalent. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. compare object identity at the callback and closed promise without reducing results to message text. Capture the reported values and failure conditions, but also preserve the calculation or event trail that led to them. A check that asserts only the last number or label can pass even when an earlier selection, conversion, grouping, state change or measurement basis was wrong.
A concise final explanation of separate cancellation reason from stored error should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, one software message or an unstated assumption. That form is short enough for revision and precise enough for a reproducible technical note.
The short answer is that if underlying cancellation cleanup rejects, the cancel request’s returned promise rejects, yet the readable stream remains closed for the consumer. Chapter 6 focuses on handle a rejecting cancel algorithm. Begin with keep initiator, reason, queue fate, cancel-algorithm promise, stored stream error, pending reads and reader.closed outcome in separate columns. Writing those facts first prevents a familiar label or final summary value from replacing the mechanism or measurement basis that actually decides the result.
Worked example. make cancel return a rejected promise C and capture both cancel rejection C and fulfilled reader.closed. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the operation, then record each conversion, selection, calculation, check or state transition in order. If a prerequisite fails, stop the trace there rather than inferring later effects from the usual path.
A useful first-principles question for handle a rejecting cancel algorithm is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. replace cancel cleanup rejection with controller.error(C); now the stream itself is errored and reader.closed rejects. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: cleanup failure after disinterest does not reopen queued data or turn the stream into an errored consumer view. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. handle both promises and assert closed stream state after the cancel rejection. Capture the reported values and failure conditions, but also preserve the calculation or event trail that led to them. A check that asserts only the last number or label can pass even when an earlier selection, conversion, grouping, state change or measurement basis was wrong.
A concise final explanation of handle a rejecting cancel algorithm should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, one software message or an unstated assumption. That form is short enough for revision and precise enough for a reproducible technical note.
The short answer is that stream.cancel rejects when the stream is locked, while the active reader’s cancel method can cancel through its owned lock. Chapter 7 focuses on respect lock-specific entry points. Begin with keep initiator, reason, queue fate, cancel-algorithm promise, stored stream error, pending reads and reader.closed outcome in separate columns. Writing those facts first prevents a familiar label or final summary value from replacing the mechanism or measurement basis that actually decides the result.
Worked example. acquire a reader, call stream.cancel(R) and record TypeError, then call reader.cancel(R) and observe underlying cleanup. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the operation, then record each conversion, selection, calculation, check or state transition in order. If a prerequisite fails, stop the trace there rather than inferring later effects from the usual path.
A useful first-principles question for respect lock-specific entry points is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. release the reader first; stream.cancel is now the valid entry point. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: a lock error says the wrong capability was used and does not prove underlying cancellation occurred. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. assert cancel callback count and stream.locked around every attempt. Capture the reported values and failure conditions, but also preserve the calculation or event trail that led to them. A check that asserts only the last number or label can pass even when an earlier selection, conversion, grouping, state change or measurement basis was wrong.
A concise final explanation of respect lock-specific entry points should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, one software message or an unstated assumption. That form is short enough for revision and precise enough for a reproducible technical note.
The short answer is that a writable destination failure normally causes pipeTo to cancel the readable source unless preventCancel is true. Chapter 8 focuses on trace cancellation during piping. Begin with keep initiator, reason, queue fate, cancel-algorithm promise, stored stream error, pending reads and reader.closed outcome in separate columns. Writing those facts first prevents a familiar label or final summary value from replacing the mechanism or measurement basis that actually decides the result.
Worked example. make the destination reject write B with D and capture source cancel(D) plus pipe rejection. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the operation, then record each conversion, selection, calculation, check or state transition in order. If a prerequisite fails, stop the trace there rather than inferring later effects from the usual path.
A useful first-principles question for trace cancellation during piping is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. set preventCancel and repeat; the source does not cancel even though the pipe fails. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: pipe rejection is coordination evidence and should not be relabelled as a producer-reported source error. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. record destination failure, prevention option, cancel callback and source readability afterward. Capture the reported values and failure conditions, but also preserve the calculation or event trail that led to them. A check that asserts only the last number or label can pass even when an earlier selection, conversion, grouping, state change or measurement basis was wrong.
A concise final explanation of trace cancellation during piping should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, one software message or an unstated assumption. That form is short enough for revision and precise enough for a reproducible technical note.
CHAPTER 9 OF 12 · Handle limits and failures
9. Do not confuse natural closure with cancellation
The short answer is that natural closure reaches done true after accepted data drains without invoking the underlying cancel algorithm. Chapter 9 focuses on do not confuse natural closure with cancellation. Begin with keep initiator, reason, queue fate, cancel-algorithm promise, stored stream error, pending reads and reader.closed outcome in separate columns. Writing those facts first prevents a familiar label or final summary value from replacing the mechanism or measurement basis that actually decides the result.
Worked example. queue A, close and read A then done true; compare with cancel before reading A. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the operation, then record each conversion, selection, calculation, check or state transition in order. If a prerequisite fails, stop the trace there rather than inferring later effects from the usual path.
A useful first-principles question for do not confuse natural closure with cancellation is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. cancel after the queue has already drained but before natural close; the cause and callback trail still differ. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: done true alone does not explain why no future chunks exist. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. require either a close-request trace, cancel callback trace or stored-error trace in the receipt. Capture the reported values and failure conditions, but also preserve the calculation or event trail that led to them. A check that asserts only the last number or label can pass even when an earlier selection, conversion, grouping, state change or measurement basis was wrong.
A concise final explanation of do not confuse natural closure with cancellation should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, one software message or an unstated assumption. That form is short enough for revision and precise enough for a reproducible technical note.
CHAPTER 10 OF 12 · Handle limits and failures
10. Preserve an observed prefix honestly
The short answer is that data delivered before either cancellation or error remains part of the consumer’s history, but it does not prove the entire source completed. Chapter 10 focuses on preserve an observed prefix honestly. Begin with keep initiator, reason, queue fate, cancel-algorithm promise, stored stream error, pending reads and reader.closed outcome in separate columns. Writing those facts first prevents a familiar label or final summary value from replacing the mechanism or measurement basis that actually decides the result.
Worked example. read records 1 and 2, then cancel in one run and error in another; publish the common prefix and distinct terminal evidence. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the operation, then record each conversion, selection, calculation, check or state transition in order. If a prerequisite fails, stop the trace there rather than inferring later effects from the usual path.
A useful first-principles question for preserve an observed prefix honestly is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. move the terminal event before record 2; the shared prefix becomes only record 1. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: terminal cause and completed work must be reported separately. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. store last acknowledged sequence with the terminal operation and reason. Capture the reported values and failure conditions, but also preserve the calculation or event trail that led to them. A check that asserts only the last number or label can pass even when an earlier selection, conversion, grouping, state change or measurement basis was wrong.
A concise final explanation of preserve an observed prefix honestly should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, one software message or an unstated assumption. That form is short enough for revision and precise enough for a reproducible technical note.
The short answer is that applications should say canceled when downstream no longer needs data and errored when the producer cannot supply valid data, reserving completed for orderly closure. Chapter 11 focuses on choose the right application language. Begin with keep initiator, reason, queue fate, cancel-algorithm promise, stored stream error, pending reads and reader.closed outcome in separate columns. Writing those facts first prevents a familiar label or final summary value from replacing the mechanism or measurement basis that actually decides the result.
Worked example. model a user leaving a preview as cancel and a corrupted source checksum as error. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the operation, then record each conversion, selection, calculation, check or state transition in order. If a prerequisite fails, stop the trace there rather than inferring later effects from the usual path.
A useful first-principles question for choose the right application language is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. treat a policy stop as application-defined; document whether it maps to cancel or error and why. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: friendly UI wording may differ, but diagnostics need the precise stream operation. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. map each application cause to operation, reason, user message and retained evidence. Capture the reported values and failure conditions, but also preserve the calculation or event trail that led to them. A check that asserts only the last number or label can pass even when an earlier selection, conversion, grouping, state change or measurement basis was wrong.
A concise final explanation of choose the right application language should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, one software message or an unstated assumption. That form is short enough for revision and precise enough for a reproducible technical note.
The short answer is that a complete receipt records initiator, operation, reason identity, queue fate, cleanup promise, pending reads, reader.closed and any pipe coordination promise. Chapter 12 focuses on build a terminal-cause receipt. Begin with keep initiator, reason, queue fate, cancel-algorithm promise, stored stream error, pending reads and reader.closed outcome in separate columns. Writing those facts first prevents a familiar label or final summary value from replacing the mechanism or measurement basis that actually decides the result.
Worked example. run the same two-chunk source through cancel R and error E and publish side-by-side event logs. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the operation, then record each conversion, selection, calculation, check or state transition in order. If a prerequisite fails, stop the trace there rather than inferring later effects from the usual path.
A useful first-principles question for build a terminal-cause receipt is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. make cancel cleanup reject and predict only the cancel request promise difference while the stream remains closed. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: a final state label without cause and promise evidence cannot distinguish these paths. Keep language semantics separate from processor strategy, host scheduling, browser support, trust policy and the meaning assigned by an application. A focused example can establish the stated mechanism without pretending to settle those broader questions.
Practical evidence check. verify no unhandled rejections, exact callback counts, one terminal transition and the expected queue fate. Capture the reported values and failure conditions, but also preserve the calculation or event trail that led to them. A check that asserts only the last number or label can pass even when an earlier selection, conversion, grouping, state change or measurement basis was wrong.
A concise final explanation of build a terminal-cause receipt should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, one software message or an unstated assumption. That form is short enough for revision and precise enough for a reproducible technical note.
Contents · Previous chapter · Return to the Websites subject guide
Frequently asked questions
Does cancel put the stream in an errored state?
No. The consumer-facing stream closes; the cancel request can still reject if cleanup fails.
Where does the cancel reason go?
It is passed to the underlying source’s cancel algorithm.
What does controller.error do to queued chunks?
It clears unread queued chunks and stores the error for reads and reader.closed.
Why can stream.cancel reject while a reader exists?
A locked stream must be canceled through its active reader or another owning algorithm.
Can earlier chunks remain valid after an error?
Yes. Already delivered data is not retroactively erased.
Is done true enough to prove natural completion?
No. Cancellation and orderly closure need their own causal evidence.
Continue through the verified reading routes
Start with the wider system
The Gold Standard of Websites · The Gold Standard of Education | Learning That Transfers into Life · How X Works hub
Compare the closest mechanisms
The Gold Standard of Websites | Separating ReadableStream.from Iterator Cancellation from Natural Exhaustion · The Gold Standard of Websites | Tracing ReadableStream tee Cancellation When One Branch Finishes First · The Gold Standard of Websites | Separating pipeTo Shutdown Controls Across preventAbort, preventCancel and preventClose · The Gold Standard of Websites | Tracing ReadableStream BYOB Minimum Fill and View Detachment · The Gold Standard of Websites | Separating pipeThrough Returned Readable from Its Internally Handled pipeTo Promise · The Gold Standard of Websites | Separating ReadableStream Close Requests from Queue Drain Completion · The Gold Standard of Websites | Separating Reader Lock Release from ReadableStream Closure
Choose the next lesson by reader job
Use the subject root to move from this focused mechanism to the next verified question. Follow a specialist link when its preconditions match your code; return to the wider hub when the next task belongs to a different system.
Authoritative sources and evidence checks
WHATWG Streams — pipeThrough method · WHATWG Streams — pipeTo method · WHATWG Streams — ReadableStreamPipeTo algorithm · WHATWG Streams — readable stream readers
The normative account follows the WHATWG Streams Living Standard. The worked fixtures report specified stream state, promise settlement and callback order; they do not infer network delivery, storage durability or application success from one fulfilled promise.