@effect/platform-bun multipart.toPersisted hangs when maxTotalSize is exceeded mid-file

[IgnisDa]

Bug

Multipart.toPersisted (and Multipart.persisted in @effect/platform-bun) hangs indefinitely when the multipart parser's maxTotalSize limit is exceeded mid-file during upload.

The request times out at 60s because the handler never completes — no response is ever sent.

Root Cause

This is caused by a bug upstream in multipasta (the multipart parsing library): the write() function returns early without forwarding the chunk to the boundary scanner when maxTotalSize is exceeded.

• multipasta bug: maxTotalSize limit mid-file leaves file part readable dangling, causing hang tim-smart/multipasta#38

The chain:

1. multipasta's write() (src/internal/multipart.ts) checks maxTotalSize before split.write(). When exceeded, it calls onError and returns — the boundary scanner never sees the chunk.
2. multipasta's web wrapper (src/web.ts): the onFile callback sets finished only when onChunk(null) is called. This never happens because the scanner never processes the boundary ending the current file part.
3. @effect/platform-bun's persisted (dist/esm/internal/multipart.js:18-44): calls reader.readMany() in a loop waiting for the file's readable stream to close. It never does → hang.
4. @effect/platform's toPersisted: uses Stream.runForEach which awaits the writer callback for each part sequentially. So the outer stream's MultipartError is never observed — the handler never completes, no response is sent.

Key Distinction

Limit	Effect
maxPartSize (per-file)	Error fires, but file readable closes normally — chunk was already forwarded to scanner
maxTotalSize (whole-request)	Error fires, but file readable hangs — scanner never sees trailing boundary

Upstream Fix

The fix is in multipasta: tim-smart/multipasta#38 — the write() method should still forward the chunk to split.write() after calling onError, so the boundary scanner can close the current file part's readable.

Once multipasta is fixed, @effect/platform-bun will need to bump the multipasta dependency.

[fubhy]

Closing this as fixed in Effect v4: v4 no longer uses multipasta, and its built-in multipart parser closes the active file part when the total size limit is exceeded before reporting the error, so BunMultipart.persisted no longer hangs.

Evidence (v4 main @ 6c59de78)

• write() calls stop(errMaxTotalSize) once the total is exceeded (multipart.ts#L245-L247), and stop ends an active file part with onChunk(null) before onError (#L94-L100).
• Regression test "propagates BodyTooLarge after the total size limit is exceeded mid-file" (Multipart.test.ts#L215-L237).
• Under Bun 1.3.13, BunMultipart.persisted with a 2 KB MaxBodySize exceeded mid-file fails promptly with MultipartError (BodyTooLarge).

On v3, #6311 bumped multipasta to ^0.2.8 (@effect/platform-bun 0.91.1), which includes the upstream fix tim-smart/multipasta#40. Thanks for the thorough root-cause analysis!

---

_{This comment is part of an AI-assisted triage of older issues and pull requests against Effect v4. The findings above were checked against the linked source, but if we got something wrong, please comment and we'll take another look.}