[vedanth-jadhav]

Ranged downloads reserve one slot for the initial response but never give that slot back to the worker pool. Once it finishes, a two-slot download runs with one worker, four slots run with three, etc. A configured limit of one also incorrectly starts a second body stream. Both non-streaming/resumed Loom imports and parallel direct video downloads use this helper.

The production change is two lines: permit zero additional workers and let the initial reader continue as a worker after finishing. Range planning, explicit write offsets, If-Match, error propagation and abort/drain behavior stay in the same pipeline. No new cache, buffer, dependency or API.

Complete download measurements

Public downloadUrlToPathParallel over real loopback HTTP, not a production WAN or complete import/transcode. Deterministic 128 MiB +123 B, 8 MiB parts, an injected 30 ms delay before each response body, otherwise unthrottled local transfer. Median milliseconds:

Slots / fixture	Before	After
1 / large	907.53	865.99
2 / large	1007.12	555.62
4 / large	702.01	684.33
16 / large (Loom default)	421.16	392.22
4 / 1 MiB single-part control	45.19	45.76
4 / large non-range control	463.44	471.85

The two-slot case saves 451.5 ms (44.8%); process ranges are 892.9–1465.4 ms before and 502.1–839.5 ms after. Four slots are very noisy (549.6–1801.3 vs 438.1–1350.7), so no robust gain is claimed there. Sixteen-slot and one-slot ranges overlap too. Controls regress by 0.57 ms and 8.41 ms with overlapping ranges; no universal improvement is claimed.

Five fresh processes per version/case, alternating order: 60 downloads. Intel Xeon Platinum 8573C, Linux x86_64, two-CPU quota and affinity 0,1, Bun 1.4.4. Timer includes file open, fetches, body reads, writes and close; fixture construction, process/import startup, readback/hash verification and cleanup are excluded. All full-file SHA-256 results and request counts match. Observed TCP connections remain 2/4/16 at those settings; the corrected one-slot case uses one instead of two. Server delay concurrency rises from 1→2, 3→4 and 15→16; that metric is separate from TCP connections and client body streams.

Correctness and reproduction

• 14 download tests pass, including new limits of 1/2/4 and a controlled blocked-body test proving the first slot is reused. Both original regressions fail on main.
• Combined locally with independent range-integrity PR fix(media-server): validate each ranged download response #3375: clean merge, all 22 tests and scoped strict TypeScript pass.
• Scoped strict source/test/benchmark TypeScript, Biome and diff checks pass. Rebased onto current main; the measured production source hash is unchanged and final tests were rerun.

Use the new maintained benchmark on both revisions (copy it to baseline before running): cd apps/media-server && bun scripts/benchmark-parallel-download.ts 2 large. Modes small and plain are controls; repeat with 1/4/16 slots, alternate versions five times, and compare emitted hashes/counts/timings. Tests: bun test src/__tests__/lib/parallel-download.test.ts src/__tests__/lib/parallel-download-concurrency.test.ts. Raw samples and the driver are preserved outside the production diff. Benchmark/test servers are ephemeral and stop on completion.

Confidence Score: 5/5

The PR appears safe to merge.

Summary

Restores the initial download slot to the worker pool after its first response finishes.

• Ranged downloads reuse the first reader's slot for more parts.

No actionable issues found. Review conclusions come from reading the code; tests and benchmarks were not run.

_{Reviews (1) · Last reviewed commit: "perf(media-server): refill the initial d..." · Reviewed by Greptile}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
cap-status	Skipped		Oct 26, 2026 12:45pm UTC