Delete temp file when http4s request body stream fails (413 leak)

[adamw]

The leak

In Http4sRequestBody, the RawBodyType.FileBody case creates a temp file via serverOptions.createFile and then compiles the body stream into it. If the stream fails mid-write — e.g. with StreamMaxLengthExceededException when the configured max content length is exceeded (resulting in a 413) — the RawValue(FileRange(file), ...) is never produced. The interpreter's body-cleanup logic only deletes files that were registered as raw values, so the temp file is never deleted.

The leak happens on every over-limit file upload, making it a disk-fill DoS vector: a client can fill the server's temp directory simply by repeatedly sending oversized bodies to a file-body (or multipart file) endpoint.

#5335 fixed exactly this in the akka, pekko, jdk-http, netty (cats/future/sync/zio) and zio-http backends, but missed http4s.

Why the shared test only catches it intermittently

The shared test checks payload limit and returns 413 on exceeded max content length (request) (ServerBasicTests) polls for leftover temp files containing the test's marker bytes. Whether the leaked file contains those bytes depends on how the HTTP client chunks the request and how much of the body was written before the limit interrupt — in local runs the leaked file is often 0 bytes, so the marker check misses it (and the oversized-request send may also end in the SttpClientException recover path). The leak itself is deterministic; only its detection is chunking-dependent. This is the source of the flaky Http4sServerTest 413 failure seen e.g. on #5373's CI.

The fix

Attach an onError handler to the stream compilation that deletes the file via serverOptions.deleteFile. onError rethrows the original error after running the handler, and the handler swallows its own failures (.attempt.void) so a failing delete cannot mask the original error. Since toRawFromStream is also used for multipart parts and by the http4s-zio interpreter, those are covered too.

Verification

• Baseline (unmodified master): http4sServer/testOnly sttp.tapir.server.http4s.Http4sServerTest -- -z 413 passes (5/5) but leaves 1 leaked /tmp/tapir*tmp file (0 bytes — confirming why the marker-based detection is intermittent).
• With the fix: the same 413 subset run 3 times — all green, 0 leaked temp files after each run.
• http4sServer2_12/compile, http4sServer3/compile, http4sServerZio/compile, http4sServerZio3/compile all succeed.
• Full Http4sServerTest suite: 302 tests, all passed, 0 leaked temp files.

🤖 Generated with Claude Code