Public ReadableStream.tee() can expose different identity rules depending on the original controller. For an ordinary readable stream, both branches normally receive the same chunk object, so a mutation through one branch can be visible through the other. For a readable byte stream, each branch receives its own copied byte chunk. Equal values therefore do not prove shared identity, and different buffer identities do not prove different source events.
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
Tee an ordinary stream that emits one mutable object and prove both branches observe the same object identity. Then tee a byte stream that emits Uint8Array [7, 8, 9] and prove the branches receive equal bytes backed by independent buffers. Mutate one result in each case, change branch order, use BYOB on one byte branch and cancel one branch. The receipt separates production count, value equality, object identity and copying.
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. Classify the original controller
Trace the decisive branch · Chapters 4–5
Handle limits and failures · Chapters 9–10
The short answer is that tee selects its default or byte-stream algorithm from the original stream’s controller type. Chapter 1 focuses on classify the original controller. Begin with keep original controller type, source production ID, branch value, object identity, backing buffer identity, byte range, mutation timing, BYOB destination and cancellation state 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 one ordinary stream emitting {score:7} and one byte stream emitting Uint8Array [7,8,9]. 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 classify the original controller 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 underlying source type to bytes and keep the displayed values similar. 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 Uint8Array chunk in an ordinary stream does not by itself turn that stream into a readable byte stream. 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 controller kind before drawing any identity conclusion. 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 classify the original controller 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 tee distributes each original result to branches without turning it into two producer events. Chapter 2 focuses on count one source production. Begin with keep original controller type, source production ID, branch value, object identity, backing buffer identity, byte range, mutation timing, BYOB destination and cancellation state 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. label the source event S1 and match both branch receipts to S1. 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 count one source production 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. construct two independent sources that each emit similar values and show why their production IDs differ. Recalculate the trace from the changed fact rather than editing the old conclusion. Name the earliest event that differs, carry that difference through the remaining steps, and say which observations stay the same because their prerequisites did not change.
The main limit is this: equal branch values do not prove how many times the underlying source ran. 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 source callback count and a stable fixture event label. 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 count one source production 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 default tee with public cloneForBranch2 false enqueues the same chunk object into both branches. Chapter 3 focuses on share ordinary object chunks. Begin with keep original controller type, source production ID, branch value, object identity, backing buffer identity, byte range, mutation timing, BYOB destination and cancellation state 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. emit object O, read both branches and prove Object.is(value1,value2) is 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 share ordinary object chunks 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. emit a primitive number and explain why identity testing does not expose a mutable shared object. 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: shared identity does not mean the branches share their queues or reader locks. 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 object identity, branch result identity and independent branch states. 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 share ordinary object chunks 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 ordinary tee branches receive the same mutable object, mutation through one reference is visible through the other. Chapter 4 focuses on observe mutation interference. Begin with keep original controller type, source production ID, branch value, object identity, backing buffer identity, byte range, mutation timing, BYOB destination and cancellation state 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. set branch-one value.score from 7 to 9 before inspecting branch two and observe 9. 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 observe mutation interference 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. freeze the source object before enqueue and capture the changed mutation outcome. 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: tee does not deep-freeze ordinary chunks or create an application isolation boundary. 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 mutation order, property descriptor and both 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 observe mutation interference 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 byte-stream tee copies each chunk so the two branches receive equal byte sequences through separate memory. Chapter 5 focuses on copy byte-stream chunks. Begin with keep original controller type, source production ID, branch value, object identity, backing buffer identity, byte range, mutation timing, BYOB destination and cancellation state 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. emit [7,8,9], read both branches and compare bytes and backing buffer identities. 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 copy byte-stream chunks 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 values to [7,8,9,10] and repeat without changing the identity rule. 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: copying does not imply a second source pull or a structured clone of arbitrary objects. 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 equal bytes, unequal relevant buffers and one source 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 copy byte-stream chunks 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 byte tee distribution, changing a byte in one branch result does not rewrite the copied result already delivered to the other branch. Chapter 6 focuses on mutate one byte branch safely. Begin with keep original controller type, source production ID, branch value, object identity, backing buffer identity, byte range, mutation timing, BYOB destination and cancellation state 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. set branch-one first byte to 99 and prove branch two still holds 7. 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 mutate one byte branch safely 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. perform the mutation before reading branch two and keep the same expected independence. 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: memory independence is limited to the branch chunks and says nothing about external source storage. 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 buffer identity, mutation time and exact arrays before and after. 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 mutate one byte branch safely 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 byte copying must preserve the chunk’s offered byteOffset and byteLength as values even though the destination branch buffers can begin at new ranges. Chapter 7 focuses on track offsets and subranges. Begin with keep original controller type, source production ID, branch value, object identity, backing buffer identity, byte range, mutation timing, BYOB destination and cancellation state 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 subview covering bytes 2 through 5 of a larger buffer and compare branch 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 track offsets and subranges is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. enqueue the full buffer instead and show the value range changes while copy independence remains. 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: backing-buffer capacity outside the view is not part of the chunk. 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 source view range and each branch’s returned byte length and values. 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 track offsets and subranges 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 byte-tee branch is itself a readable byte stream, so a consumer can use a BYOB reader and receive bytes copied into its supplied pull-into path. Chapter 8 focuses on use byob on one branch. Begin with keep original controller type, source production ID, branch value, object identity, backing buffer identity, byte range, mutation timing, BYOB destination and cancellation state in separate columns. Writing those facts first prevents a familiar label or final summary value from replacing the mechanism or measurement basis that actually decides the result.
Worked example. read branch one with a four-byte BYOB view while branch two uses a default reader. 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 use byob on one branch 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. swap reader types across branches and keep the source production count unchanged. 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: BYOB adds another memory handoff and must not be confused with the tee’s branch-copy rule. 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 source chunk, tee copy, supplied destination view, detachment and returned view. 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 use byob on one branch 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. Keep branch pace separate from identity
The short answer is that one branch can receive or inspect its result earlier, but temporal order does not change whether objects are shared or byte chunks are copied. Chapter 9 focuses on keep branch pace separate from identity. Begin with keep original controller type, source production ID, branch value, object identity, backing buffer identity, byte range, mutation timing, BYOB destination and cancellation state 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. delay branch two by one task in both ordinary and byte fixtures. 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 branch pace separate from 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. reverse the delays and compare only timing fields. 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 first branch to read does not become the owner of the source event for identity purposes. 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 event order and identity conclusions independently. 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 branch pace separate from 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 10 OF 12 · Handle limits and failures
10. Cancel without rewriting delivered chunks
The short answer is that cancelling one branch changes future tee coordination but does not merge or retroactively copy values already delivered. Chapter 10 focuses on cancel without rewriting delivered chunks. Begin with keep original controller type, source production ID, branch value, object identity, backing buffer identity, byte range, mutation timing, BYOB destination and cancellation state 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. deliver S1 to both branches, cancel branch two and continue branch one to S2. 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 cancel without rewriting delivered chunks 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 before S1 arrives and follow which live branch receives the later source chunk. 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: cancellation reason propagation is a separate mechanism from branch chunk identity. 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 delivery cut-off, canceled flags and source cancel timing. 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 cancel without rewriting delivered chunks 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 value equality, serialization output and developer-console displays cannot establish whether two branch results share memory or object identity. Chapter 11 focuses on avoid false copy claims. Begin with keep original controller type, source production ID, branch value, object identity, backing buffer identity, byte range, mutation timing, BYOB destination and cancellation state 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. compare JSON text for two ordinary objects and show it misses Object.is evidence. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the operation, then record each conversion, selection, calculation, check or state transition in order. If a prerequisite fails, stop the trace there rather than inferring later effects from the usual path.
A useful first-principles question for avoid false copy claims 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. compare equal byte arrays with buffer identity and a controlled mutation check. 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: mutation tests must use isolated fixtures and should not corrupt production 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. publish identity predicates, buffer checks and pre/post values rather than screenshots alone. 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 false copy claims 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 controller kind, one source event, branch values, object or buffer identity, mutation result and consumer mode. Chapter 12 focuses on build a branch-identity receipt. Begin with keep original controller type, source production ID, branch value, object identity, backing buffer identity, byte range, mutation timing, BYOB destination and cancellation state 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 ordinary object O and byte chunk B through matched two-branch fixtures. 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 branch-identity 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 the ordinary chunk to a Uint8Array without changing controller type and predict shared identity there. 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 proves public tee behavior for the fixture rather than universal copy-on-write implementation details. 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 source count, value equality, correct identity rule and independent queue settlements. 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 branch-identity 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
Do ordinary tee branches receive copies of an object?
With public tee on an ordinary stream, both branches normally receive the same chunk object.
Do byte-stream tee branches share one ArrayBuffer?
No. Each branch receives its own copied byte chunk.
Does equal output prove shared identity?
No. Equal values can come from shared objects or independent copies.
Is a Uint8Array always copied by tee?
Only the byte-stream controller selects byte-tee copying; a Uint8Array in an ordinary stream follows ordinary tee identity rules.
Can one branch use BYOB after tee?
Yes, when the original was a readable byte stream and the branch is therefore a byte stream.
How should copying be tested?
Count source events, compare identity or buffers, and use a controlled mutation with exact before-and-after bytes.
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 | 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 BYOB respond Byte Counts from respondWithNewView View Replacement · The Gold Standard of Websites | Separating ByteLengthQueuingStrategy Chunk Size from Queue Capacity · The Gold Standard of Websites | Separating ReadableByteStreamController enqueue from Fulfilling a Live BYOB Request · The Gold Standard of Websites | Separating Pending Pull-Into Descriptor Commit from Ordinary Byte-Queue Draining · The Gold Standard of Websites | Separating ReadableStream tee Branch Backpressure from Source Pull Scheduling
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 — ReadableStream tee · WHATWG Streams — ReadableStreamTee · WHATWG Streams — byte-stream tee · WHATWG Streams source repository
The normative mechanism follows the WHATWG Streams Living Standard, last updated 25 October 2026 when checked for this article. The worked byte sequences, queue ledgers and callback logs are original teaching fixtures. They establish the specified stream behavior; they do not claim network delivery, storage durability or application acceptance.