Concatenate two streaming bodies. When both sides are chunked the result preserves chunk boundaries from each operand — useful for multipart builders that already chose their chunk shape. Mixing buffered and chunked merges through to_chunks so the result is still walkable chunk-by-chunk by downstream consumers.

Byte size of the body. Constant-time for Buffered; walks the chunk list (summing bit_array.byte_size) for Chunked. For Source it drains the callback to count — single-pass, so the stream is consumed by the call. Callers who need to know the size without consuming the body should track it themselves alongside the StreamingBody value.

Generic capped-buffered collection: takes the Result produced by a <op>_streaming wrapper and materialises the body as a BitArray, refusing if size would exceed max_bytes. Works against any service’s streaming wrapper since the wrappers all return Result(streaming.Response, _).

Typical “download a smallish-bounded object” case: small JSON / config blobs / log shards where the wire bytes fit in memory but the caller wants a hard ceiling. For multi-GB objects skip this helper and consume chunks via fold_chunks directly.

Same as collect_to_bit_array_max but also runs the bytes through bit_array.to_string, surfacing Error(InvalidUtf8) when the body isn’t valid UTF-8. Common path for streaming text responses (JSON / XML / log shards) where the caller wants the bytes both size-bounded AND UTF-8-validated in a single hop.

Buffered empty body. Used by request builders when no body is present (the SDK threads a StreamingBody end-to-end even for GET-style operations).

Reduce a streaming body left-to-right by accumulating one chunk at a time. Buffered bodies surface as a single chunk per to_chunks, so the fold runs once; chunked bodies fold across every chunk the transport delivered; Source bodies stream chunks one-by-one without materialising — next is called once per fold step. Use this for running-hash / running-length / stream-to-disk pipelines without buffering the full body.

Build a StreamingBody from a BitArray already in memory. Use this when the body bytes are buffered up front (a UTF-8 payload, the result of a buffered read, a generated XML/JSON body) and you want to pass a StreamingBody-typed value through.

Build a StreamingBody from an ordered list of byte chunks. Chunk boundaries are preserved by to_chunks and by append when both operands are chunked, so multipart builders and the chunked transport see exactly the chunking the caller produced.

Build a StreamingBody from a pull-based callback. Each call to next returns the next chunk; Error(Nil) marks end-of- stream. The callback is invoked once per fold_chunks step (so multi-GB payloads stream without ever materialising the full body), and once per element when to_chunks materialises.

Single-pass: once a Source has been folded / materialised, the callback is exhausted and subsequent calls return Error. Callers that need to consume the same body twice should reconstruct the body fresh on the second pass.

Build a StreamingBody from a UTF-8 String. Common path for caller-supplied text payloads (JSON bodies, XML bodies); equivalent to from_bit_array(bit_array.from_string(s)).

True iff the body is empty. For Buffered / Chunked it’s a direct check; for Source it returns False conservatively without consuming the callback — a Source could yield zero chunks, but checking would require calling next() which is destructive (single-pass). Callers who need a definitive answer should call byte_size instead, accepting the consumption cost.

Return the body as a BitArray. For Buffered this is a constant-time accessor; for Chunked it concatenates the chunks. For Source it materialises the whole stream — defeats the point of streaming, so chunk-by-chunk consumers should prefer to_chunks / fold_chunks instead.

Materialise the body as a BitArray, refusing to do so if the cumulative size would exceed max_bytes. Walks chunks lazily on the chunked path so the cap fires before concatenation. Use this when a caller wants buffered access but must guard against OOM on pathologically-large responses (event-stream control- message buffers, downloads of unknown size, server bugs).

Error(Nil) means the body exceeded the cap; the caller can fall back to chunk-by-chunk processing or surface a typed error to its own callers. A max_bytes of 0 still accepts the empty body (Ok(<<>>)).

Return the body as an ordered list of byte chunks. Buffered bodies surface as a single-element list (or the empty list if the buffer is empty), so consumers can write one chunk-oriented loop and have it work uniformly across both representations. Source bodies are materialised by draining the callback — expensive for large streams; use fold_chunks to stream element-by-element without materialising.

Materialise the body as a UTF-8 String. Returns Error(Nil) if the body exceeds max_bytes (via to_bit_array_max) OR if the bytes aren’t valid UTF-8. The two-failure-modes-one-error shape mirrors bit_array.to_string so callers can keep their existing result.try chains.

Common path for text response bodies — JSON-as-text, XML-as- text, log files — where the caller wants both size-safety and a String result. Equivalent to to_bit_array_max followed by bit_array.to_string, kept here as a single entry point so call sites read as one operation.

fold_chunks variant that short-circuits on Error. Returns the first error the folder produces (or Ok(acc) if every chunk accepted). Useful for streaming decoders that can fail partway (e.g. UTF-8 validation rejecting a torn multi-byte sequence at a chunk boundary, or a JSON parser hitting a malformed token).