Closing and aborting a WritableStream both end ordinary writing, but they express different contracts. Close waits for queued writes and then asks the sink to finish cleanly. Abort starts an error path, discards queued work that has not begun, signals an in-flight operation through the controller’s AbortSignal, and invokes the sink’s abort algorithm instead of its close algorithm.
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
Begin with one underlying sink that logs start, write, close and abort. Then run the same queued chunks through clean close and forced abort. The later chapters isolate queued versus in-flight writes, close/abort races, lock rules, callback failures and the difference between stream completion and durable storage.
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 the two terminal intentions
Trace the decisive branch · Chapters 4–5
Change one premise · Chapters 6–8
6. Invoke the sink close algorithm
Handle limits and failures · Chapters 9–10
Verify and explain · Chapters 11–12
The short answer is that close requests orderly completion after accepted writes, whereas abort reports that successful writing can no longer continue and moves the stream toward an errored result. Chapter 1 focuses on name the two terminal intentions. Begin with track stream state, queued and in-flight writes, controller.signal, sink close, sink abort and each returned promise independently. 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. construct a sink that logs write, close and abort; run one stream through writer.close and another through writer.abort(‘stop’). 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 the two terminal intentions 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 controller.error instead; the stream errors from the sink side without treating that external signal as a producer-requested close. 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-looking APIs are not interchangeable merely because later writes fail in every 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. assert which sink callback ran, the stored reason, writer.closed settlement and final desiredSize. 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 the two terminal intentions 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 close places a close request after queued chunks so the sink’s close callback runs only after those writes finish successfully. Chapter 2 focuses on let close drain queued writes. Begin with track stream state, queued and in-flight writes, controller.signal, sink close, sink abort and each returned promise independently. 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 writes A and B, gate each sink write, call writer.close and verify close remains pending until both gates resolve in order. 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 let close drain queued writes 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. reject write B; close now rejects and the sink close callback is not a successful finalization path. 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: calling close prevents later writes but does not leap ahead of already accepted queue entries. 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 write request order, gate settlement, close callback time, close promise and writer.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 let close drain queued writes 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 abort starts erroring and queued writes that have not become in-flight do not receive ordinary successful processing. Chapter 3 focuses on let abort discard queued work. Begin with track stream state, queued and in-flight writes, controller.signal, sink close, sink abort and each returned promise independently. 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. hold write A in flight, queue B and C, then call writer.abort(‘operator-stop’); release A and compare the three write promises. 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 let abort discard queued work 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 abort with close; B and C are processed before sink close, so the earliest difference is queue disposition. 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: abort does not rewind side effects already performed by an in-flight sink write. 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. count sink write invocations and distinguish an invoked write from a queued request that rejects before invocation. 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 let abort discard queued work 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 controller’s signal is aborted when the stream is aborted, giving an underlying sink a way to stop a pending write or close operation. Chapter 4 focuses on signal an in-flight operation. Begin with track stream state, queued and in-flight writes, controller.signal, sink close, sink abort and each returned promise independently. 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. inside sink write, listen to controller.signal and reject with its reason when abort occurs; verify the write and abort promises settle through the defined path. 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 signal an in-flight operation 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. ignore the signal and finish the in-flight write; the stream still follows abort state, but the sink chose not to stop that operation early. 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 AbortSignal is a notification mechanism, not an automatic rollback of external I/O. 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 signal.aborted, signal.reason, sink side effects and every promise settlement. 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 signal an in-flight operation 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 after the stream finishes the required erroring transition, the configured underlying sink abort callback receives the producer’s reason and can release resources. Chapter 5 focuses on invoke the sink abort algorithm. Begin with track stream state, queued and in-flight writes, controller.signal, sink close, sink abort and each returned promise independently. 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. open a mock resource in start, write one chunk, abort with a structured marker and close the resource in sink abort. 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 invoke the sink abort 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. omit the abort callback; the stream can still abort, but application-specific resource cleanup must be supplied elsewhere. 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 abort promise confirms the configured abort process settled; it does not prove every remote system reversed prior work. 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 reason identity, resource state, callback count and lack of sink close. 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 invoke the sink abort 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 the underlying sink close callback runs only after queued writes succeed and is the place to flush or finalize orderly output. Chapter 6 focuses on invoke the sink close algorithm. Begin with track stream state, queued and in-flight writes, controller.signal, sink close, sink abort and each returned promise independently. 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. stage bytes during write, flush them during close and fulfill writer.close only after the flush gate resolves. 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 invoke the sink close 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. make the flush reject; close and writer.closed reject, showing that requesting close is not proof of successful finalization. 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: sink close should not be used as a generic error cleanup hook because abort follows a different callback. 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 staged bytes, flush result, close settlement, resource release and zero abort callbacks. 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 invoke the sink close 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.close and stream.abort reject when the stream is locked, while the active writer exposes close and abort operations for that locked stream. Chapter 7 focuses on respect stream and writer locks. Begin with track stream state, queued and in-flight writes, controller.signal, sink close, sink abort and each returned promise independently. 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 writer, show stream.locked true, call writer.close successfully and compare stream.close rejecting during the lock. 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 stream and writer locks 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 lock first and call stream.abort on a still-writable stream; the method can now own the operation directly. 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 selects the active producer interface; it is not evidence that a close or abort already 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. record lock holder, method used, synchronous call result and returned promise rejection or 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 respect stream and writer locks 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 once close is queued or in flight, later terminal calls follow state-specific rules and an abort cannot be assumed to interrupt an in-flight close callback. Chapter 8 focuses on resolve a close and abort race. Begin with track stream state, queued and in-flight writes, controller.signal, sink close, sink abort and each returned promise independently. 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. gate sink close, call writer.close, then attempt writer.abort and observe the specified settlements and controller signal behavior. 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 resolve a close and abort race 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. abort before close is queued; now the stream takes the abort path and a later close cannot restore orderly 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: wall-clock closeness does not make operations simultaneous; the first accepted state transition controls later behavior. 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 gates and numbered calls rather than timers, then assert callback counts and promise reasons. 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 resolve a close and abort race 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 rejected sink write, close or abort promise affects different requests and stream states, so failures need exact callback labels. Chapter 9 focuses on propagate sink callback failures. Begin with track stream state, queued and in-flight writes, controller.signal, sink close, sink abort and each returned promise independently. 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 sink abort reject with cleanup error A after producer abort reason P and record the abort promise and writer.closed results. 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 propagate sink callback failures 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 sink close reject with C instead; the stream errors during orderly finalization and no abort callback is implied. 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 generic catch block can hide whether data writing, final flush or forced cleanup failed. 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. attach a phase field to each error and include it in the terminal 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 propagate sink callback failures 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. Keep close separate from controller.error
The short answer is that controller.error is a sink-side declaration that future interactions fail with a supplied error; it does not ask the sink’s close callback to finalize output. Chapter 10 focuses on keep close separate from controller.error. Begin with track stream state, queued and in-flight writes, controller.signal, sink close, sink abort and each returned promise independently. 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 controller.error(‘device-fault’) from an external event while writes are queued and observe rejected writer promises. 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 keep close separate from controller.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. instead return a rejected promise from sink write; the stream reaches an error through the write algorithm rather than an out-of-band controller call. 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.error is rarely a substitute for returning a precise rejected sink 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. record the external trigger, queue contents, stored error and whether close or abort callbacks ran. 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 keep close separate from controller.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 the meaning of sink write and close fulfillment is defined by the sink implementation, so durable storage or remote acknowledgement must be represented explicitly. Chapter 11 focuses on separate stream success from durability. Begin with track stream state, queued and in-flight writes, controller.signal, sink close, sink abort and each returned promise independently. 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. let write mean accepted into an in-memory staging buffer and close mean fsync acknowledgement in the fixture; report both moments. 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 stream success from durability 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. change close to release the resource without fsync; the stream still closes under that sink contract but durability is no longer established. 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: Streams provides ordering and state machinery, not a universal durability guarantee. 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. name the sink contract and test the external receipt that supports any durability claim. 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 stream success from durability 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 useful receipt states the initial lock, queued and in-flight chunks, terminal call, controller signal, sink callback, resource result and promise settlements. Chapter 12 focuses on build a terminal-action receipt. Begin with track stream state, queued and in-flight writes, controller.signal, sink close, sink abort and each returned promise independently. 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 matched close and abort fixtures with chunks A, B and C and publish the two ordered event logs side by side. 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-action 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. change only the timing of abort relative to write A and predict which queued requests never reach the sink. 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 fixture proves the bounded sink contract and does not generalize to resources whose abort or close semantics 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. retain callback arguments, resource state, final stored error and explicit disposal steps. 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-action 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 abort call the sink’s close callback?
No. Abort uses the underlying sink abort algorithm; orderly close uses the close algorithm.
What happens to queued writes on close?
They are processed in order before the sink close callback runs.
What happens to queued writes on abort?
Writes that have not begun can be discarded and reject; an in-flight operation may already have effects.
Why does the controller expose a signal?
It lets the sink notice that an in-flight write or close operation is being aborted.
Can stream.abort be called while a writer holds the lock?
The stream method rejects while locked. Use the active writer’s abort method or release the lock first.
Does a fulfilled close prove durable storage?
Only if the sink’s documented close contract and an external receipt establish durability.
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 TransformStream Backpressure from Writable Write Completion · The Gold Standard of Websites | Separating CompressionStream Input Chunks from Compressed Output Chunks · The Gold Standard of Websites | Separating Response Body Locked State from Disturbed State · The Gold Standard of Websites | Tracing ReadableStream BYOB Minimum Fill and View Detachment · The Gold Standard of Websites | Separating pipeTo Shutdown Controls Across preventAbort, preventCancel and preventClose · The Gold Standard of Websites | Separating Writer Lock Release from WritableStream Closure · The Gold Standard of Websites | Separating ByteLengthQueuingStrategy Chunk Size from Queue Capacity
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 — WritableStream class · WHATWG Streams — underlying sink API · WHATWG Streams — WritableStreamDefaultController · WHATWG Streams — writable stream abstract operations
The normative account follows the WHATWG Streams Living Standard. The examples treat sink callbacks as application contracts: a fulfilled stream write or close does not automatically prove physical durability or a remote acknowledgement.