Calling a readable stream controller’s close method can request closure while queued chunks still remain. The stream becomes observably closed only after those chunks are read. The close-request flag, queue contents, individual read results and reader.closed therefore mark different stages of one orderly ending.
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
Start with an unlocked default readable stream whose controller enqueues A and B, then requests close. Record close request, queue size, each read result, the final done result and reader.closed settlement. The later chapters change queue order, add pending reads, compare error and cancel paths, and show why no more chunks may be enqueued after close is requested.
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. Distinguish request from completion
Trace the decisive branch · Chapters 4–5
Change one premise · Chapters 6–8
6. Change only the queue at close time
Handle limits and failures · Chapters 9–10
Verify and explain · Chapters 11–12
The short answer is that controller.close requests orderly closure, but a nonempty queue keeps the readable stream available until the stored chunks are consumed. Chapter 1 focuses on distinguish request from completion. Begin with keep controller close request, queue contents, pending read requests, stream state, read result and reader.closed settlement on separate timelines. 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. enqueue A and B, call close, then inspect reads A and B before the first done true result. 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 distinguish request from completion 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. call close before enqueuing anything; with an empty queue, closure can complete immediately. 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 close request is not permission to discard queued chunks and is not identical to consumer cancellation. 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. log controller action, queue events, read results and reader.closed settlement as distinct events. 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 distinguish request from completion 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 each queued chunk is delivered with done false before a later read observes done true after the queue becomes empty. Chapter 2 focuses on drain chunks before done true. Begin with keep controller close request, queue contents, pending read requests, stream state, read result and reader.closed settlement on separate timelines. 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. enqueue three numbered chunks, request close and perform four reads to obtain 1, 2, 3, then done true. 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 drain chunks before done true 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. consume one chunk before requesting close; only the remaining queued chunks delay completion. 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 describes that read result and does not rewrite earlier chunk results. 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 value and done fields for every read rather than counting only total calls. 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 drain chunks before done true 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 3 OF 12 · Build the first model
3. Settle reader.closed at the terminal transition
The short answer is that reader.closed fulfills when the stream reaches the closed state, which can occur after a close request but before or alongside a final read callback depending on the queued state. Chapter 3 focuses on settle reader.closed at the terminal transition. Begin with keep controller close request, queue contents, pending read requests, stream state, read result and reader.closed settlement on separate timelines. 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. capture reader.closed before draining A and show it remains pending until A leaves the queue. 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 settle reader.closed at the terminal transition 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. capture reader.closed after the queue already drained; it is already tied to the closed stream. 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 promise callback’s microtask order must not be confused with the earlier state transition that resolved it. 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. use explicit event labels and one microtask checkpoint after each controlled read. 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 settle reader.closed at the terminal transition 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 4 OF 12 · Trace the decisive branch
4. Reject enqueue after close is requested
The short answer is that once close has been requested, later enqueue calls are invalid even while previously queued chunks are still readable. Chapter 4 focuses on reject enqueue after close is requested. Begin with keep controller close request, queue contents, pending read requests, stream state, read result and reader.closed settlement on separate timelines. 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. enqueue A, call close, attempt enqueue B and record the thrown TypeError while A remains available. 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 reject enqueue after close is requested 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 enqueue B before close; both chunks become part of the orderly drain. 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: remaining readable data does not imply that the producer may add more data. 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 the synchronous exception and separately read every chunk accepted before the close request. 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 reject enqueue after close is requested 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 when reads are already pending, enqueued chunks can fulfill them directly, and a close request fulfills remaining read requests with done true once no queued data remains. Chapter 5 focuses on serve pending reads around close. Begin with keep controller close request, queue contents, pending read requests, stream state, read result and reader.closed settlement on separate timelines. 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 two reads, enqueue A and close; one read receives A and the other receives done true. 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 serve pending reads around close 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. start three reads and enqueue A and B before close; two reads receive chunks and one receives done true. 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: pending reads are requests, not queued chunks, and require their own ledger. 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 each read promise and record which controller action settles it. 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 serve pending reads around close 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 the decisive condition for immediate close completion is whether the relevant queue and pending pull-into state permit closure, not how long the stream has existed. Chapter 6 focuses on change only the queue at close time. Begin with keep controller close request, queue contents, pending read requests, stream state, read result and reader.closed settlement on separate timelines. 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 one fixture with queue empty at close and one with A queued, comparing the earliest closed observation. 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 change only the queue at close time 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 a byte stream with a partially filled BYOB request; additional byte-stream rules can delay or shape the final result. 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 default-stream example cannot be copied unchanged to every byte-stream pull-into case. 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. state stream type and queue or pull-into state before applying the closure rule. 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 change only the queue at close time 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 7 OF 12 · Change one premise
7. Separate source closure from consumer cancellation
The short answer is that orderly close preserves queued chunks for reading, while cancellation expresses disinterest and discards queued data before running the underlying cancel algorithm. Chapter 7 focuses on separate source closure from consumer cancellation. Begin with keep controller close request, queue contents, pending read requests, stream state, read result and reader.closed settlement on separate timelines. 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, close in one fixture and cancel with reason R in another; compare delivered chunks and cancel callback count. 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 source closure from consumer 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 only after reading A; B is discarded while A remains an already observed prefix. 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: both paths can end with a closed consumer view, but their data retention and cleanup causes differ. 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 delivered values, discarded queue count, cancel reason and terminal state. 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 source closure from consumer 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.
The short answer is that controller.error clears the queue and errors the stream, so pending and later reads reject instead of draining queued chunks to done true. Chapter 8 focuses on separate close request from producer error. Begin with keep controller close request, queue contents, pending read requests, stream state, read result and reader.closed settlement on separate timelines. 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) and prove the next read rejects E without yielding the queued values. 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 close request from producer 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. read A before erroring; the observed prefix remains, while B is cleared and the next read 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: an error does not retroactively erase data already delivered, but it does change unread queue fate. 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. capture prefix, stored error identity, rejected reads and reader.closed 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 separate close request from producer 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.
CHAPTER 9 OF 12 · Handle limits and failures
9. Handle repeated or invalid terminal calls
The short answer is that a second close call or a terminal action after closure follows precondition rules and must not be treated as another independent completion. Chapter 9 focuses on handle repeated or invalid terminal calls. Begin with keep controller close request, queue contents, pending read requests, stream state, read result and reader.closed settlement on separate timelines. 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. call close twice while A is queued and record the second call’s failure without duplicating the final done result. 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 repeated or invalid terminal calls 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 the second close with controller.error; it is also invalid once close has been requested. 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: controller methods are stateful controls, not idempotent application notifications. 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 one accepted close request, one terminal transition and the exact rejected controller call. 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 repeated or invalid terminal calls 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. Avoid equating pull completion with stream closure
The short answer is that the promise returned by an underlying pull algorithm can fulfill while queued data and the stream remain readable; close requires an explicit controller action or another specified source path. Chapter 10 focuses on avoid equating pull completion with stream closure. Begin with keep controller close request, queue contents, pending read requests, stream state, read result and reader.closed settlement on separate timelines. 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. fulfill pull after enqueuing A but do not call close; read A and show a later read can request another pull. 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 avoid equating pull completion with stream closure 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. call close at the end of pull; the same A is followed by orderly done true. 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: producer callback completion is not stream completion. 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. log pull start and fulfillment separately from controller.close and reader.closed. 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 avoid equating pull completion with stream closure 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 producer should stop scheduling new data before requesting close and should account for every already accepted chunk that consumers may still drain. Chapter 11 focuses on design an orderly producer ending. Begin with keep controller close request, queue contents, pending read requests, stream state, read result and reader.closed settlement on separate timelines. 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. produce sequence numbers 7 and 8, mark producer stopped, request close and let the consumer acknowledge both. 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 design an orderly producer ending 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. request close while an external producer callback still plans 9; its later enqueue fails and reveals the coordination bug. 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: closeRequested protects stream integrity but does not coordinate unrelated application tasks automatically. 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 producer stop flag, last accepted sequence, close request and final consumer acknowledgement. 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 design an orderly producer ending 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 distinguishes accepted enqueues, queue state, close request, rejected later enqueues, read results, reader.closed and underlying cleanup callbacks. Chapter 12 focuses on build a closure-stage receipt. Begin with keep controller close request, queue contents, pending read requests, stream state, read result and reader.closed settlement on separate timelines. 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 A and B through normal close, then change the terminal action to error E and publish the two traces. 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 closure-stage 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. cancel after A in a third transfer check and predict which remaining evidence changes. 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 terminal label is insufficient to distinguish orderly drain, cancellation and failure. 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 all read promises handled, one accepted terminal path and exact preservation or removal of queued chunks. 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 closure-stage 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 controller.close discard queued chunks?
No. In an orderly close, accepted queued chunks remain readable before done true.
When does reader.closed fulfill?
When the stream reaches its closed state, which may be after a nonempty queue drains.
Can the source enqueue after requesting close?
No. A later enqueue is invalid.
Is a close request the same as cancel?
No. Cancel expresses consumer disinterest and can discard queued data.
What happens if the source errors after queuing data?
Unread queued data is cleared and reads reject with the stored error.
Does an underlying pull promise fulfilling close the stream?
No. The controller must take the specified close action.
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 | Tracing ReadableStream BYOB Minimum Fill and View Detachment · The Gold Standard of Websites | Separating ByteLengthQueuingStrategy Chunk Size from Queue Capacity · The Gold Standard of Websites | Separating pipeThrough Returned Readable from Its Internally Handled pipeTo Promise · The Gold Standard of Websites | Separating ReadableStream Cancellation from Producer-Reported Errors · 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.