pipeThrough starts the same underlying pipe machinery used by pipeTo, marks that internal promise as handled and returns the supplied pair’s readable side. The returned stream is therefore a route for transformed output, not the promise that reports completion of the hidden pipe. A reliable diagnosis follows the returned readable, the source and destination states, and the internally handled pipe as separate lines of 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
Begin with a source, a readable-writable pair and four explicit identities: the source, transform.writable, transform.readable and the value returned by pipeThrough. Trace synchronous precondition checks before any pull. Then run normal completion, source failure, transform-writable failure, prevention options and AbortSignal shutdown. The final receipt shows how to observe failure through endpoint states without pretending pipeThrough returned the pipe promise.
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
Trace the decisive branch · Chapters 4–5
Change one premise · Chapters 6–8
6. Trace a writable-side failure backward
7. Apply prevention options by direction
8. Abort the internal pipe without losing the returned identity
Handle limits and failures · Chapters 9–10
9. Handle a readable that outlives the pipe action
10. Avoid inferring hidden-promise status from unhandledrejection
Verify and explain · Chapters 11–12
The short answer is that pipeThrough returns the readable member of the supplied pair, not a new wrapper and not the promise created for the pipe operation. Chapter 1 focuses on name the returned object. Begin with keep the source, pair members, returned readable, internal pipe operation, lock state, propagation option and each terminal observation 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. construct a pair with named readable R and writable W, call source.pipeThrough(pair), and prove the returned value is exactly 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 name the returned object 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 R with a separately named pass-through readable while keeping W fixed; the returned identity changes even though the source-side call is otherwise identical. 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: return identity alone says nothing about whether the pipe will later finish successfully. 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 strict identity, initial lock flags and the absence of any promise methods on the returned stream. 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 returned object 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 pipeThrough checks whether the source or supplied writable is already locked before starting the pipe and throws synchronously when either check fails. Chapter 2 focuses on run synchronous precondition checks. Begin with keep the source, pair members, returned readable, internal pipe operation, lock state, propagation option and each terminal observation 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. lock the source with a reader, call pipeThrough inside a synchronous try-catch and record TypeError before any source pull or destination write. 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 run synchronous precondition checks 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 source but lock the pair’s writable with a writer; the failure moves to the second lock precondition. 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 synchronous throw is different from a later rejected stream read and should not be reported through the returned readable. 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 pull and write callbacks and require both to remain zero after a precondition failure. 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 run synchronous precondition checks 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. Separate the hidden promise from the returned readable
The short answer is that the pipe algorithm creates a promise whose handled flag is set internally, while callers receive the readable side and must observe that stream’s data and terminal state. Chapter 3 focuses on separate the hidden promise from the returned readable. Begin with keep the source, pair members, returned readable, internal pipe operation, lock state, propagation option and each terminal observation 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. pipe A through a transform that enqueues A1, read A1 from the returned readable and separately log source closure and destination finalization. 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 the hidden promise from the returned readable 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 pipeTo with the same writable instead; the caller now receives the coordination promise rather than the readable side. 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: handled does not mean fulfilled and does not erase errors; it only prevents the unreturned promise from being treated as unhandled. 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 observations to returnedReader.closed, reads and explicit endpoint callbacks rather than inventing access to the hidden promise. 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 the hidden promise from the returned readable 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. Follow ordinary completion through the pair
The short answer is that normal source closure propagates to the supplied writable unless preventClose is true, after which transformed output drains and the returned readable reaches its own close path. Chapter 4 focuses on follow ordinary completion through the pair. Begin with keep the source, pair members, returned readable, internal pipe operation, lock state, propagation option and each terminal observation 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. send A and B through a TransformStream, read both outputs, close the source and record transform flush before 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 follow ordinary completion through the pair 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 preventClose true; data can transfer while the transform writable remains open and the returned readable need not close yet. 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: successful reads of a prefix do not prove that flush ran or that the returned readable has closed. 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 input close, final write, flush, final output, done true and reader.closed in order. 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 ordinary completion through the pair 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. Trace a source failure into readable evidence
The short answer is that a source error normally aborts the supplied writable, and the transform’s readable side can become errored even though pipeThrough returned no promise to reject to the caller. Chapter 5 focuses on trace a source failure into readable evidence. Begin with keep the source, pair members, returned readable, internal pipe operation, lock state, propagation option and each terminal observation 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. enqueue A, then error the source with marker E; read the successful prefix and capture the next read and reader.closed 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 a source failure into readable evidence 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 preventAbort true; the hidden pipe still fails, but the supplied writable is not aborted and its readable-side outcome follows the pair’s own logic. 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 observed output prefix is compatible with a later stream error and cannot be promoted to whole-pipeline success. 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 marker identity at source error, destination abort and returned-reader rejection where the chosen pair propagates 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 trace a source failure into readable evidence 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 an error in the supplied writable normally cancels the source, while the returned readable’s observation depends on the pair and any output already enqueued. Chapter 6 focuses on trace a writable-side failure backward. Begin with keep the source, pair members, returned readable, internal pipe operation, lock state, propagation option and each terminal observation 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 transform reject input B after output A, then capture source cancel, returned read A and the later terminal 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 a writable-side failure backward 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 true; the source receives no cancel request although the internal pipe still 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: preventCancel changes backward cleanup and does not guarantee the returned readable will produce more output. 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 cancel count, unread source values and returned-reader terminal evidence under matched fixtures. 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 a writable-side failure backward 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 preventClose, preventAbort and preventCancel retain the same directional meanings in pipeThrough as in pipeTo even though the call returns a readable stream. Chapter 7 focuses on apply prevention options by direction. Begin with keep the source, pair members, returned readable, internal pipe operation, lock state, propagation option and each terminal observation 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 three small fixtures, changing one terminal trigger and only its governing option in each. 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 apply prevention options by direction 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. turn on all three options but abort through signal; preventAbort and preventCancel affect signal cleanup while preventClose remains irrelevant. 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 options do not expose the internal promise or combine endpoint lifecycles into one state. 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. publish a trigger-to-action table beside callback counts and terminal observations. 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 apply prevention options by direction 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 8 OF 12 · Change one premise
8. Abort the internal pipe without losing the returned identity
The short answer is that an AbortSignal can stop the active pipe while the returned value remains the same readable object, whose later state must be inspected separately. Chapter 8 focuses on abort the internal pipe without losing the returned identity. Begin with keep the source, pair members, returned readable, internal pipe operation, lock state, propagation option and each terminal observation 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. gate the destination write, abort with reason R and record cancel, abort and returned-reader outcomes. 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 abort the internal pipe without losing the returned identity 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 pipeThrough is called with an already-aborted signal; synchronous return still produces R if lock checks pass, followed by shutdown work. 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: object identity surviving shutdown is not evidence that the object remains readable or healthy. 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 returned identity before awaiting any terminal promise, then record reason propagation and final locks. 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 abort the internal pipe without losing the returned identity 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 a readable that outlives the pipe action
The short answer is that with prevention options or a custom pair, the returned readable can remain open after the source-to-writable pipe has stopped, so ownership of final closure belongs to the pair’s design. Chapter 9 focuses on handle a readable that outlives the pipe action. Begin with keep the source, pair members, returned readable, internal pipe operation, lock state, propagation option and each terminal observation 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. use preventClose with a TransformStream, finish the source, then explicitly close the transform’s writable and observe the readable close. 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 readable that outlives the pipe action 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 explicit close; the consumer can remain waiting even though no more source chunks will arrive. 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 completion and readable completion are related by the pair’s algorithms, not by the return statement itself. 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. bound the fixture with timers used only as test guards and prove which callback is missing. 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 readable that outlives the pipe action 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 inferring hidden-promise status from unhandledrejection
The short answer is that pipeThrough marks the internal pipe promise handled, so a missing unhandledrejection event is expected and cannot prove successful piping. Chapter 10 focuses on avoid inferring hidden-promise status from unhandledrejection. Begin with keep the source, pair members, returned readable, internal pipe operation, lock state, propagation option and each terminal observation 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. cause a controlled source error, listen for unhandledrejection, and still observe the returned reader’s rejection and endpoint callbacks. 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 inferring hidden-promise status from unhandledrejection 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 pipeTo without catching its returned promise; now the host can report an unhandled rejection if the test intentionally leaves it unobserved. 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: host rejection notification is not a normative completion receipt for pipeThrough. 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 every promise the fixture owns and use stream state rather than absence of a global event. 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 inferring hidden-promise status from unhandledrejection 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 11 OF 12 · Verify and explain
11. Choose an observation surface deliberately
The short answer is that applications should attach error handling to the returned readable and pair-specific endpoints because pipeThrough intentionally optimizes chaining rather than exposing the pipe promise. Chapter 11 focuses on choose an observation surface deliberately. Begin with keep the source, pair members, returned readable, internal pipe operation, lock state, propagation option and each terminal observation 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. build source.pipeThrough(t1).pipeThrough(t2), consume the final readable and log both transform error boundaries. 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 an observation surface deliberately 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 first call with pipeTo; chaining disappears because the returned value answers coordination rather than providing readable output. 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 chain needs an explicit consumer and endpoint error policy; merely constructing it does not drain 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. record every pair identity, lock interval, read loop and terminal promise in a bounded chain. 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 an observation surface deliberately 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 states synchronous checks, returned identity, lock ownership, input and output events, option values, cleanup callbacks and the terminal evidence available on the returned readable. Chapter 12 focuses on build a pipethrough receipt. Begin with keep the source, pair members, returned readable, internal pipe operation, lock state, propagation option and each terminal observation 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 A and B through one transform, then change B to a controlled failure and publish both ordered 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 pipethrough 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. set preventAbort in the failing case and predict only the destination cleanup difference while retaining the same return identity. 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 receipt establishes one specified pipeline and does not prove transport or application acceptance beyond the stream pair. 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 invented pipe promise, no unhandled fixture promises, exact error identity and one terminal outcome per endpoint. 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 pipethrough 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 pipeThrough return a promise?
No. It returns the readable member of the supplied readable-writable pair.
What happens to the internal pipe promise?
The algorithm marks it handled. Its effects still appear through stream states and callbacks.
Can pipeThrough throw immediately?
Yes. Locked source or writable preconditions produce a synchronous TypeError.
How do I observe a later failure?
Consume the returned readable, observe reader.closed, and record the pair’s relevant callbacks.
Does preventClose also prevent abort?
No. Each prevention option governs one propagation direction.
Why is there no unhandledrejection?
The internal promise is marked handled; absence of that host event does not prove success.
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 pipeTo Shutdown Controls Across preventAbort, preventCancel and preventClose · The Gold Standard of Websites | Separating TransformStream Backpressure from Writable Write Completion · The Gold Standard of Websites | Separating Response Body Locked State from Disturbed State · The Gold Standard of Websites | Separating ReadableStream.from Iterator Cancellation from Natural Exhaustion · The Gold Standard of Websites | Separating ReadableStream Close Requests from Queue Drain Completion · 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.