[Self-Hosted] media-proxy intermittently fails S3 reads with "transport chunk exceeded its byte bound"

(#872) Bug Needs triage media self-hosting

Thread

Comment by @FrigidSouls
RexSystem 1 vote originally by @FrigidSouls on GitHub OP
Additional A/B testing rules out SeaweedFS 4.47 as the source of the regression. I still have my previous self-hosted Fluxer installation and its original SeaweedFS data volume. That environment uses:
  • SeaweedFS 4.34
  • The exact same fluxer-media-proxy:v1 image/digest as the new installation:sha256:740e236db7ad9efd9cc1213ba769d6d8e9e24a079975a1cb431539d58fceba5c
I started only the old SeaweedFS 4.34 container and tested the same 122,994,218-byte MP4. Direct AWS CLI S3 downloads against SeaweedFS 4.34: SUCCESS=20 FAILURE=0 I then started the existing media-proxy container and accessed media-proxy directly over the Docker network, bypassing Nginx and Caddy. 20 identical sequential requests for: /attachments/<id>/<id>/video.mp4?format=webp&width=64 produced: SUCCESS=15 FAILURE=5 All five failures reported the same error: object storage operation failed: object storage response transport chunk exceeded its byte bound Therefore the issue reproduces with both SeaweedFS 4.34 and 4.47 while direct S3 GETs against both versions succeed 20/20. Current comparison:
  • SeaweedFS 4.34 + AWS CLI: 20/20
  • SeaweedFS 4.47 + AWS CLI: 20/20
  • media-proxy + SeaweedFS 4.34: 15/20
  • media-proxy + SeaweedFS 4.47: intermittently fails, with multiple tests ranging from 8/20 to 3/20 successful
  • media-proxy image digest is identical in both environments
This appears to further isolate the problem to the current media-proxy S3 response-reading path rather than a specific SeaweedFS version.