fix(media): Range requests to /media return 500 when storage is Cloudflare R2

[jdconley]

Describe the bug

GET /media/{sha256} with a Range header fails when media storage is Cloudflare R2. The relay advertises accept-ranges: bytes on the full response, so clients trust it and then get an error:

• Range: bytes=0-1023 → 500 {"error":"internal error"}
• Range: bytes=0-99 → 416

A request with no Range header returns 200 with the complete body, so the object and the key resolve correctly.

This breaks video playback entirely, since players use range requests to stream and seek. Images are unaffected because they are fetched whole.

Steps to reproduce

1. Configure the relay with BUZZ_S3_ENDPOINT pointing at a Cloudflare R2 bucket (https://<account>.r2.cloudflarestorage.com).
2. Upload a video through Buzz Desktop.
3. curl -r 0-1023 https://<relay>/media/<sha256> → 500.
4. curl https://<relay>/media/<sha256> (no Range) → 200, full body.

Expected behavior

206 Partial Content with Content-Range: bytes 0-1023/<total>, per the behaviour documented at crates/buzz-relay/src/api/media.rs (RFC 9110 §14.2).

Version and platform

• Buzz version: relay ghcr.io/block/buzz:sha-63496cc
• OS: Ubuntu 24.04, Docker Compose, media on Cloudflare R2

Logs / additional context

Isolated to the relay — R2 itself handles ranges correctly:

Check	Result
R2 ranged GetObject (aws-cli, same key/creds)	ContentRange: bytes 0-1023/9896517, 1024 bytes
R2 HeadObject	ContentLength=9896517, AcceptRanges=bytes
Sidecar _meta/**.json	"size": 9896517 (correct)
Relay full GET	200, all 9896517 bytes
Relay ranged GET	500

Both relay paths resolve the same key via resolve_s3_key and both call head_with_metadata, so key resolution and total size are not the difference. The only divergence is in buzz-media::storage:

• get_stream → bucket.get_object_stream(key) — works
• get_range → bucket.get_object_range(key, start, Some(end)) — fails

A get_range failure surfaces as MediaError::StorageError, which matches the 500. This looks like a rust-s3 get_object_range incompatibility with R2 rather than a bug in the range parsing, which behaves correctly.

Relay log for the failing request:

level=ERROR message="response failed" classification="Status code: 500 Internal Server Error" latency="1206 ms" target=tower_http::trace::on_failure http.request.method=GET

Not reproduced against MinIO or AWS S3 — R2 is the only backend tested here, so this may be R2-specific S3 interop. Possibly adjacent to #2470 (S3-interop failure on GCS), though that is the git object store rather than media.

[iroiro147]

Picking this up. Clear repro + identified seam at crates/buzz-relay/src/api/media.rs. I'll check the Range parsing/satisfiability logic + the S3 client GetObject range forwarding, fail-first a test pinning the 500/416 paths, then ship the minimal fix. Intent: no behavior change on the happy path ( full body), only correct the ranged branch. Will comment with the PR once opened.

[iroiro147]

Diagnosis so far — need one log line to pin it

Thanks for the detailed report. I've traced this end-to-end on current main (d88313f36, identical relay/media code to your sha-63496cc deploy), and there's exactly one unresolved step.

What the relay actually does (crates/buzz-relay/src/api/media.rs serve_blob_for_tenant, range branch):

1. Sidecar gate → resolve key (your _meta/**.json read, size=9896517, is fine).
2. total = head_with_metadata(key) → HEAD on the object → reads Content-Length.
3. parse_byte_range("bytes=0-1023", total) → (0, 1023).
4. 0 < total ⇒ not the 416 branch.
5. end is clamped to ≤ min(total-1, start+16MiB-1) ⇒ get_range(key, 0, 1023)
   → bucket.get_object_range sends Range: bytes=0-1023 (correctly SigV4-signed, range in SignedHeaders).
6. head_with_metadata's ? and get_range's ? are the only MediaError::StorageError producers in this path, and StorageError is the only variant that returns HTTP 500.

So on the code as written:

• bytes=0-1023 can only 500 via step 6.
• bytes=0-99 → 416 can only happen if parse_byte_range returned None, which for start=0, total=9896517 is impossible — unless total isn't actually 9896517 (i.e., the HEAD Content-Length isn't what the sidecar claims) or the 416 is being generated by something else.

The one thing I need: when you reproduce this, the relay logs a line:

ERROR ... "media storage error"  error=<the exact S3Error>

That error= string is the decisive evidence — it carries the HTTP status and R2's XML error body (e.g. HttpFailWithBody(416, "<Error>…InvalidRange…</Error>") vs a HEAD failure), which tells us whether the 500 is the GET or the HEAD, and whether R2 is rejecting the signed range or the HEAD is returning a wrong/zero Content-Length.

Could you paste that log line (with RUST_LOG=buzz_relay=debug if needed) for the bytes=0-1023 → 500 case, and confirm the response headers on the bytes=0-99 → 416 (specifically any Content-Range)?

I have a narrow fix staged (map HttpFailWithBody(416) → relay 416, and normalize the open-ended-range end before it hits R2), but I don't want to ship it blind against a guess about R2's wire behavior.

[iroiro147]

I've opened PR #4079 which I believe addresses this.

What's in the PR

1. Diagnostic fix first: the original report couldn't easily tell us why S3 range GETs were failing — rust-s3 wraps upstream non-2xx responses in S3Error::HttpFailWithBody(status, body), but buzz was collapsing that into a generic StorageError, producing the opaque 500 {"error":"internal error"} with no trace of the upstream status or body. That's why the request for logs in this issue didn't yield anything actionable. The PR now logs tracing::warn!(s3_status, s3_body, key, start, end) on that path, so any future R2/S3 range rejection is directly visible.

2. Fallback for the 500: when the S3 range GET fails for a reason other than 404, we now fall back to a full object GET and slice [start..(end+1).min(len)] in memory, returning the usual 206 + Content-Range (or 416 when out of bounds). This unwires the S3 range rejected → 500 fast-path entirely. Response headers, chunking, and the existing MAX_RANGE_CHUNK bound are unchanged on the happy path.

3. Tests: unit tests covering the slice math, clamping behaviour at MAX_RANGE_CHUNK, and a regression case matching your 9,896,517-byte object.

Given you verified the same range works against R2 via aws s3api directly, the most likely culprit was a non-range error (e.g. auth/expiry on that specific request, or R2 returning something non-2xx in an edge case) being silently discarded. With this PR it'll either (a) work transparently via the fallback and you'll see the reason in logs, or (b) surface the real upstream error. Happy to adjust the approach if maintainers prefer strict range-only fail-fast — the diagnostic logging is independently worth shipping either way.