supabase / supabase-swift / 35083288060

89%

push

github

perf(helpers)!: stream request bodies instead of buffering them before upload (#1342)

* perf(helpers): stream request bodies instead of buffering them before upload

URLSessionTransport collected every .stream body into memory with no cap before starting the request. On Apple platforms it now sends them through uploadTask(withStreamedRequest:), with StreamingTaskDelegate answering needNewBodyStream by bridging the body's chunks into a bound InputStream/OutputStream pair. The bridge pulls one chunk at a time and writes only while the stream has space, so memory stays at the pair's buffer plus one chunk. A second body-stream request replays a .multiple body and fails a .single one with HTTPBodyAlreadyConsumedError. .unknown length omits Content-Length so URLSession uses chunked transfer. Linux keeps buffering, capped at 64 MiB (HTTPBodyTooLargeError).

HTTPBody.init(_ chunks:), init(fileURL:) and reportingProgress are pull-based now (AsyncThrowingStream(unfolding:)) instead of pumping the source into an unbounded stream from a detached Task, which is what kept the streamed upload at two copies. reportingProgress keeps the receiver's storage, so a file body still uploads flat; its progress comes from didSendBodyData through the new package-level HTTPBody.onUploadProgress.

Memory probe upload-transport-stream, 200 MiB body: +377.5 MB before, +5.9 MB after. The probe (MemoryProbeIntegrationTests, opt-in via MEMORY_PROBE=1) is included so the number is reproducible.

Refs SDK-1842

Co-Authored-By: Claude <noreply@anthropic.com>

* test(helpers): assert the Linux transport collects a streamed body before the request starts

The in-flight pull assertion only holds on Apple platforms; swift-corelibs-foundation has no per-task delegate to feed a body stream from, so the transport buffers first there by design.

Co-Authored-By: Claude <noreply@anthropic.com>

* fix(helpers)!: harden streamed request bodies after review

- Fail a `.known(n)` streamed body that ... (continued)

186 of 195 new or added lines in 4 files covered. (95.38%)

10520 of 11888 relevant lines covered (88.49%)

148.67 hits per line