A custom queuing-strategy size callback can return a large valid nonnegative finite number, throw, or return an invalid size such as -1, NaN or Infinity. A large valid size is enqueued and can make desiredSize zero or negative, producing backpressure. A thrown or invalid size instead takes an abrupt path that errors the relevant stream machinery. Negative desiredSize is therefore evidence of accepted queued cost, not proof that the size callback failed.
This specialist guide belongs to the Websites root. It also connects to The Gold Standard of Education | Learning That Transfers into Life and the How X Works hub. The worked cases are original teaching examples; their values and event logs are stated so each conclusion can be checked.
eduKateSG · Websites
Find your next learning step
Use highWaterMark 4 with chunks labelled A, B and C. Let size(A) return 6, let size(B) throw E and let size(C) return Infinity in separate streams. Track callback execution, queue entry, queueTotalSize, desiredSize, ready or pull behavior, write/read promise settlement and stored error. Then repeat on readable, writable and transform sides.
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
Change one premise · Chapters 6–8
Handle limits and failures · Chapters 9–10
Verify and explain · Chapters 11–12
The short answer is that the size callback measures a chunk while the high-water mark provides a threshold used to derive desiredSize. Chapter 1 focuses on separate measurement from capacity. Begin with keep chunk identity, size callback result, completion kind, numeric validation, queue entry, queueTotalSize, high-water mark, desiredSize, backpressure, stored error and promise settlement 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 HWM 4 and size(A) 6, then calculate desiredSize -2. 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 measurement from capacity 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. raise HWM to 8 without changing A and recalculate desiredSize 2. 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 high-water mark is not a per-chunk acceptance limit. 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 size result, queue total, HWM and 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 separate measurement from capacity 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 nonnegative finite size is enqueued even when it crosses the high-water mark and creates backpressure. Chapter 2 focuses on accept a large finite size. Begin with keep chunk identity, size callback result, completion kind, numeric validation, queue entry, queueTotalSize, high-water mark, desiredSize, backpressure, stored error and promise settlement 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 with size 6 under HWM 4 and preserve its queue entry. 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 accept a large finite size 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 size 4 so desiredSize reaches exactly zero. 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: negative desiredSize is a valid state rather than an exception. 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 enqueue success, queue membership and controller state. Capture the reported values and failure conditions, but also preserve the calculation or event trail that led to them. A check that asserts only the last number or label can pass even when an earlier selection, conversion, grouping, state change or measurement basis was wrong.
A concise final explanation of accept a large finite size 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 accepted queue cost influences desiredSize, pull eligibility or writer.ready without automatically rejecting the chunk operation. Chapter 3 focuses on observe backpressure evidence. Begin with keep chunk identity, size callback result, completion kind, numeric validation, queue entry, queueTotalSize, high-water mark, desiredSize, backpressure, stored error and promise settlement 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. hold the sink, write A of size 6 and inspect writer.ready and the write promise separately. 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 backpressure 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. let the sink consume A immediately and observe backpressure clear. 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: ready state and a particular write’s completion answer different questions. 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 ready promise identity, write promise and queue drain. 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 backpressure 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 abrupt callback completion is handled as a stream error path rather than a queue-pressure calculation. Chapter 4 focuses on throw from the size callback. Begin with keep chunk identity, size callback result, completion kind, numeric validation, queue entry, queueTotalSize, high-water mark, desiredSize, backpressure, stored error and promise settlement 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 size(B) throw Error E before B is enqueued. 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 throw from the size callback 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. return 6 for B instead and compare the valid oversized 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: a thrown callback provides no chunk size to add to queueTotalSize. 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 callback entry, thrown reason, absent B queue entry and terminal state. Capture the reported values and failure conditions, but also preserve the calculation or event trail that led to them. A check that asserts only the last number or label can pass even when an earlier selection, conversion, grouping, state change or measurement basis was wrong.
A concise final explanation of throw from the size callback 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 enqueue-with-size requires a nonnegative number, so -1 produces a RangeError abrupt completion. Chapter 5 focuses on reject negative size. Begin with keep chunk identity, size callback result, completion kind, numeric validation, queue entry, queueTotalSize, high-water mark, desiredSize, backpressure, stored error and promise settlement 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. return -1 for C and capture the resulting error 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 reject negative size 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. return 0 for C and show that zero is accepted even though it adds no queue cost. 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: invalid size is a contract failure and not ordinary negative desiredSize. 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 raw return, validation result and stored exception class. Capture the reported values and failure conditions, but also preserve the calculation or event trail that led to them. A check that asserts only the last number or label can pass even when an earlier selection, conversion, grouping, state change or measurement basis was wrong.
A concise final explanation of reject negative size 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 NaN fails the nonnegative-number test and positive Infinity is explicitly rejected as a queued item size. Chapter 6 focuses on reject nan and infinity. Begin with keep chunk identity, size callback result, completion kind, numeric validation, queue entry, queueTotalSize, high-water mark, desiredSize, backpressure, stored error and promise settlement 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 matched NaN and Infinity callbacks and compare RangeError 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 reject nan and infinity 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 Number.MAX_VALUE as a finite changed case and show it remains valid even with extreme pressure. 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 infinite high-water mark can be valid while an infinite chunk size is not. 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 finiteness, HWM value, queue mutation and error class. Capture the reported values and failure conditions, but also preserve the calculation or event trail that led to them. A check that asserts only the last number or label can pass even when an earlier selection, conversion, grouping, state change or measurement basis was wrong.
A concise final explanation of reject nan and infinity 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 for a readable default controller, size failure during enqueue errors the stream and resets queued state. Chapter 7 focuses on trace a readable enqueue failure. Begin with keep chunk identity, size callback result, completion kind, numeric validation, queue entry, queueTotalSize, high-water mark, desiredSize, backpressure, stored error and promise settlement 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 validly, then enqueue B whose size throws E. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the operation, then record each conversion, selection, calculation, check or state transition in order. If a prerequisite fails, stop the trace there rather than inferring later effects from the usual path.
A useful first-principles question for trace a readable enqueue failure is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. read A before B is attempted and compare the preserved historical result with later rejection. 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 pending read may bypass queuing and therefore bypass the size callback for that 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. record whether a read request was pending, callback count, queue reset and read outcomes. 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 readable enqueue failure should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, one software message or an unstated assumption. That form is short enough for revision and precise enough for a reproducible technical note.
The short answer is that a writable controller obtains chunk size before queueing the write; failure starts erroring and rejects affected writer promises. Chapter 8 focuses on trace a writable size failure. Begin with keep chunk identity, size callback result, completion kind, numeric validation, queue entry, queueTotalSize, high-water mark, desiredSize, backpressure, stored error and promise settlement 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. write A validly, then write B whose size callback throws E. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the operation, then record each conversion, selection, calculation, check or state transition in order. If a prerequisite fails, stop the trace there rather than inferring later effects from the usual path.
A useful first-principles question for trace a writable size failure 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. wait until A fully completes before B and compare in-flight versus queued evidence. 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 size callback error is distinct from a rejection returned by the sink write algorithm. 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 callback failed and each write promise reason. Capture the reported values and failure conditions, but also preserve the calculation or event trail that led to them. A check that asserts only the last number or label can pass even when an earlier selection, conversion, grouping, state change or measurement basis was wrong.
A concise final explanation of trace a writable size failure 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 transform readable and writable strategies have separate size algorithms and high-water marks. Chapter 9 focuses on trace a transform strategy failure. Begin with keep chunk identity, size callback result, completion kind, numeric validation, queue entry, queueTotalSize, high-water mark, desiredSize, backpressure, stored error and promise settlement 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. configure a writable size callback that throws on B and verify transform(B) is not treated as ordinary queued work. 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 transform strategy failure is: what must already be true before this step can run? Use the rule above to separate the input contract from the result. Follow object identity, state and returned value independently. Two branches can print similar data while differing in ownership, timing, brand or future capability.
Now change exactly one premise. move the failing callback to the readable strategy and trigger it when transformed output is enqueued. 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 side on which measurement fails determines the immediate algorithm path. 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 writable input callback, transform callback, readable output callback and side 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 trace a transform strategy failure 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 size algorithms run at specific queueing points and not as periodic measurements of already queued objects. Chapter 10 focuses on keep callback timing visible. Begin with keep chunk identity, size callback result, completion kind, numeric validation, queue entry, queueTotalSize, high-water mark, desiredSize, backpressure, stored error and promise settlement 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. mutate A after enqueue and show its recorded size does not automatically recalculate. 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 callback timing visible 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. mutate A before enqueue and let the callback observe the changed fixture. 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: queue cost is captured by the algorithm call rather than live-linked to object properties. 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 callback invocations and retain returned 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 keep callback timing visible 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 slowly drained valid queue can remain pressured for time without being errored, while size failure is terminal regardless of drain speed. Chapter 11 focuses on compare failure with slow draining. Begin with keep chunk identity, size callback result, completion kind, numeric validation, queue entry, queueTotalSize, high-water mark, desiredSize, backpressure, stored error and promise settlement 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 consumer for A size 6 and later release it. Treat every stated value as part of a controlled teaching fixture. Record the starting state before the operation, then record each conversion, selection, calculation, check or state transition in order. If a prerequisite fails, stop the trace there rather than inferring later effects from the usual path.
A useful first-principles question for compare failure with slow draining 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. throw E for B while the consumer is fast. 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: elapsed waiting and stream failure must be established from state and promise evidence. 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 queue total over time, terminal state and rejection 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 compare failure with slow draining should state the starting state, the governing rule, the ordered outcome and one boundary. It should not depend on a screenshot, one software message or an unstated assumption. That form is short enough for revision and precise enough for a reproducible technical note.
The short answer is that a complete receipt records callback input, returned or thrown completion, numeric validation, queue mutation, desiredSize and promise outcomes. Chapter 12 focuses on build a sizing receipt. Begin with keep chunk identity, size callback result, completion kind, numeric validation, queue entry, queueTotalSize, high-water mark, desiredSize, backpressure, stored error and promise settlement 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=6, B=throw E, C=Infinity in independent fresh streams. 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 sizing 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 C to zero and predict successful enqueue with unchanged queue total. 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 validates queue semantics for the fixture rather than memory usage or network buffering. 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 each callback runs once, every accepted size is accounted for and failures add no queue entry. 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 sizing 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
Can a chunk larger than the high-water mark be accepted?
Yes. A valid size can cross the threshold and make desiredSize zero or negative.
Does negative desiredSize mean the size callback failed?
No. It usually reflects accepted queued cost above the threshold.
What happens when the callback throws?
The relevant stream algorithm follows an error path and the chunk is not queued with a size.
Are negative, NaN or infinite chunk sizes valid?
No. Enqueueing such sizes produces a RangeError path.
Is an infinite high-water mark the same as an infinite chunk size?
No. The standard allows an infinite high-water mark, while enqueue-with-size rejects infinite chunk size.
What should a test record?
Callback completion, numeric validation, queue mutation, desiredSize, stream state and promise reasons.
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 ByteLengthQueuingStrategy Chunk Size from Queue Capacity · The Gold Standard of Websites | Separating ReadableStream desiredSize from Pull Eligibility · The Gold Standard of Websites | Separating TransformStream Backpressure from Writable Write Completion · The Gold Standard of Websites | Separating WritableStream Abort from Underlying Sink Close · The Gold Standard of Websites | Separating ReadableByteStreamController Error Cleanup from Pending BYOB Read Rejection · The Gold Standard of Websites | Tracing BYOB Reader Release with a Partially Filled Pull-Into Descriptor · The Gold Standard of Websites | Separating TransformStream Controller Termination from Controller-Reported Errors
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 — queuing strategies · WHATWG Streams — enqueue a value with size · WHATWG Streams — readable controller enqueue · 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 buffers, queues, promise settlements and callback logs are original teaching fixtures. They establish the specified stream behavior; they do not claim network delivery, storage durability or application acceptance.