Receive uploads: add streaming direct upload path #1

New issue

Open

opened 2026-05-06 04:58:50 +02:00 by jesse · 0 comments

jesse commented

2026-05-06 04:58:50 +02:00

Owner

Background

Direct receive uploads below the multipart threshold still parse the request through request.formData(). This follow-up tracks a streaming-safe direct upload path or an explicit threshold/API adjustment if streaming multipart form parsing is not viable on Workers.

Source: Deferred from receive links fix pass after PR multi-agent code review
File: worker.js:3280
Branch: feature/receive-links-foundation

Failure mode

Browser direct uploads below 90 MiB enter handleReceiveUploadSmall.
The handler calls request.formData() before writing file bytes to R2.
Near-threshold requests can buffer the body in Worker memory and fail under runtime pressure before the multipart path is used.

Why deferred from receive links fix pass

A true streaming fix may require changing the browser upload protocol or adding a multipart parser, which is larger than the review-fix scope.
The current fix pass preserved the public receive page behavior and focused on correctness, reservation safety, and retryability.

Proposed work

Evaluate whether the direct receive path should switch from multipart/form-data to a streaming raw-body endpoint with metadata in headers or query parameters.
Add a streaming implementation that writes file bytes to R2 without fully materializing the file body in Worker memory.
Preserve validation for auth, Turnstile/password gates, extension rules, quotas, and finalization ledgers.
Update the receive page direct-upload request shape if the endpoint changes.
Update API and feature docs to describe the final direct-upload threshold and protocol.

Acceptance

Tests assert valid direct receive uploads still finalize successfully.
Tests assert over-threshold files use multipart and do not enter the direct upload path.
Tests assert missing or invalid metadata fails before R2 mutation.
Documentation states whether direct receive uploads are streaming or intentionally capped below the runtime buffering risk.

References

Follow-up from feature/receive-links-foundation receive-links review fix pass.

## Background Direct receive uploads below the multipart threshold still parse the request through `request.formData()`. This follow-up tracks a streaming-safe direct upload path or an explicit threshold/API adjustment if streaming multipart form parsing is not viable on Workers. **Source:** Deferred from receive links fix pass after PR multi-agent code review **File:** `worker.js:3280` **Branch:** `feature/receive-links-foundation` ## Failure mode - Browser direct uploads below 90 MiB enter `handleReceiveUploadSmall`. - The handler calls `request.formData()` before writing file bytes to R2. - Near-threshold requests can buffer the body in Worker memory and fail under runtime pressure before the multipart path is used. ## Why deferred from receive links fix pass - A true streaming fix may require changing the browser upload protocol or adding a multipart parser, which is larger than the review-fix scope. - The current fix pass preserved the public receive page behavior and focused on correctness, reservation safety, and retryability. ## Proposed work - [ ] Evaluate whether the direct receive path should switch from `multipart/form-data` to a streaming raw-body endpoint with metadata in headers or query parameters. - [ ] Add a streaming implementation that writes file bytes to R2 without fully materializing the file body in Worker memory. - [ ] Preserve validation for auth, Turnstile/password gates, extension rules, quotas, and finalization ledgers. - [ ] Update the receive page direct-upload request shape if the endpoint changes. - [ ] Update API and feature docs to describe the final direct-upload threshold and protocol. ## Acceptance - Tests assert valid direct receive uploads still finalize successfully. - Tests assert over-threshold files use multipart and do not enter the direct upload path. - Tests assert missing or invalid metadata fails before R2 mutation. - Documentation states whether direct receive uploads are streaming or intentionally capped below the runtime buffering risk. ## References - Follow-up from `feature/receive-links-foundation` receive-links review fix pass.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

jesse/ycloud-cloudflare#1

No description provided.

Rows
Columns