supabase / storage / 42080649567

88%

push

github

fix(tus): fail resumed writes when the request stream dies early (#1669)

## What kind of change does this PR introduce?

Bug fix

## What is the current behavior?

On Node 26, TUS uploads can crash the process with:

```
A FileHandle object was closed during garbage collection. This used to be allowed with a deprecation warning but is now considered an error. Please close FileHandle objects explicitly. File descriptor: 1477 (/tmp/bYZ1tLT50Q-0)
code: ERR_INVALID_STATE
```

Node 26 raises this as an `uncaughtException`, and
`src/start/shutdown.ts` exits the process. On Node 24 it was only a
deprecation warning, so the leak was there before the Node 26 bump but
didn't show up.

#1658 hardened the chunk splitter against being destroyed mid-chunk.
This is a different path, still present in v1.89.11. It happens when a
PATCH resumes an upload that has an incomplete part in S3:

1. Upstream `S3Store.write()` makes several S3 calls before it reads the
body (metadata, ListParts, download and delete of the incomplete part).
2. If the request stream errors during those calls (e.g. the
`StreamLimiter` rejects an oversized chunked body), it emits
`error`/`close` before anyone listens.
3. `write()` then builds `new MultiStream([incompletePart, src])`.
MultiStream streams the incomplete part into the splitter, which opens
chunk 0, then switches to the dead stream and waits forever.
4. The error response is already sent and the lock released, so nothing
references the stuck pipeline. GC closes the open chunk handle and the
process crashes.

Each stuck write also keeps its part-upload permit forever, so the
semaphore drains until TUS uploads stall on the instance.

`@tus/s3-store` 2.1.0 / `@tus/utils` 0.7.3 have the same code, so
upgrading does not fix it.

## What is the new behavior?

- `S3Store` overrides `write()`. It matches upstream, except the
incomplete part is joined with a `pipeline()`-based `concatStreams`
instead of `MultiStream`. `pipeline()` reports a ta... (continued)

8374 of 10108 branches covered (82.85%)

Branch coverage included in aggregate %.

27 of 29 new or added lines in 1 file covered. (93.1%)

14286 of 15864 relevant lines covered (90.05%)

1281.69 hits per line