RexSystem1 voteoriginally 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.
Thread
Comment by @FrigidSouls
- SeaweedFS 4.34
- The exact same
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:fluxer-media-proxy:v1image/digest as the new installation:sha256:740e236db7ad9efd9cc1213ba769d6d8e9e24a079975a1cb431539d58fceba5cSUCCESS=20 FAILURE=0I 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=64produced:SUCCESS=15 FAILURE=5All five failures reported the same error:object storage operation failed: object storage response transport chunk exceeded its byte boundTherefore 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.