RexSystem1 voteoriginally by @FrigidSouls on GitHub OP
Additional control test: I reproduced the issue on a clean Debian 12 VM.
Test environment:
Debian 12 (bookworm), kernel 6.1
Docker Engine 29.8.1
SeaweedFS 4.34
Same restored SeaweedFS data
Same ghcr.io/fluxerapp/fluxer-media-proxy:v1 image/digest as the original deployment
Exact media-proxy runtime environment copied from the original container, with only the SeaweedFS endpoint changed for the test Docker network
Requests made directly to media-proxy over the Docker network, bypassing Nginx/Caddy
Before testing media-proxy, I performed 20 complete downloads of the same 122,994,218-byte MP4 directly from SeaweedFS S3 using AWS CLI. All 20 succeeded.
I then made 20 identical requests directly to media-proxy:
/attachments/.../video.mp4?format=webp&width=64
Results:
HTTP 200: 10/20
HTTP 502: 10/20
Every failed request reported the same error:
object storage operation failed: object storage response transport chunk exceeded its byte bound
Successful and failed requests were interspersed, so the same object and identical request can either succeed or fail.
This reproduces the problem on Debian 12 as well as Debian 13, and with SeaweedFS 4.34 as well as 4.47. Combined with reliable direct S3 downloads, this appears to rule out the Debian version, reverse proxy, migrated object corruption, and a SeaweedFS-4.47-specific regression as primary causes.
The remaining evidence points toward the media-proxy S3 response-reading/client path or an interoperability issue between that client path and SeaweedFS's S3 responses.
Thread
Comment by @FrigidSouls
- Debian 12 (bookworm), kernel 6.1
- Docker Engine 29.8.1
- SeaweedFS 4.34
- Same restored SeaweedFS data
- Same
- Exact media-proxy runtime environment copied from the original container, with only the SeaweedFS endpoint changed for the test Docker network
- Requests made directly to media-proxy over the Docker network, bypassing Nginx/Caddy
Before testing media-proxy, I performed 20 complete downloads of the same 122,994,218-byte MP4 directly from SeaweedFS S3 using AWS CLI. All 20 succeeded. I then made 20 identical requests directly to media-proxy:ghcr.io/fluxerapp/fluxer-media-proxy:v1image/digest as the original deployment/attachments/.../video.mp4?format=webp&width=64Results:- HTTP 200: 10/20
- HTTP 502: 10/20
Every failed request reported the same error:object storage operation failed: object storage response transport chunk exceeded its byte boundSuccessful and failed requests were interspersed, so the same object and identical request can either succeed or fail. This reproduces the problem on Debian 12 as well as Debian 13, and with SeaweedFS 4.34 as well as 4.47. Combined with reliable direct S3 downloads, this appears to rule out the Debian version, reverse proxy, migrated object corruption, and a SeaweedFS-4.47-specific regression as primary causes. The remaining evidence points toward the media-proxy S3 response-reading/client path or an interoperability issue between that client path and SeaweedFS's S3 responses.