Repository navigation
Conversation
downloadChunk retried a failed request or an unexpected status, but once the 206 came back a body that broke off or stalled until the client timeout failed the chunk, and with it the whole load. Read the body inside the same backoff op, so a broken off body is retried like any other failure, with the same 4 attempts, 1s apart. A chunk that receives no bytes for 10s is abandoned and retried instead of waiting out the 30s client timeout. The first chunk now goes through the same path.
vLX42
force-pushed
the
fix/chunk-read-retry
branch
from
October 21, 2026 19:12
89d334c to
9adc687
Compare
vLX42
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resuming the WAN Show episode "I Need To Start Ad Blocking - WAN Show October 16, 2026" (
spotify:episode:53W7y9ml2LKRQ6rAoQb6nf, ~3.5h, 230 chunks) from my phone at 1h51m failed to load. The seek lands on chunk 120, the CDN starts the 206 and then stalls, and the read runs into the 30s client timeout:Nothing is loaded after that, so the client shows no position on the timeline and a seek from the phone fails with
no primary stream.downloadChunkretried a failed request or a wrong status, but a body that broke off after the 206 was not retried, so one stalled chunk killed the whole load.Changes in
audio/chunked-reader.go:downloadChunknow does the request, the status check and the body read in the existing backoff op and returns the data. A body that breaks off is retried like any other failure, same policy as before: 4 attempts, 1s apart, stops when the reader is closed.chunkStallTimeout) cancels the attempt and it is retried, instead of waiting out the 30s client timeout. A slow body that keeps sending is not affected, the timer resets on every read with data.NewHttpChunkedReadergoes through the same path, so a stall on chunk 0 of a fresh load is retried too.Tests:
TestFetchChunkRetriesABrokenOffBody: first body fails mid-read, second succeeds.TestFetchChunkRetriesAStalledBody: first body never sends a byte, the stall timer kicks in and the retry succeeds.TestNewReaderRetriesABrokenOffFirstChunk: same for chunk 0.TestFetchChunkDoesNotMultiplyStatusRetries: a 403 still takes exactly 4 requests.The first three fail on master (the stall one hangs). Existing close/backoff tests pass unchanged.
go test -count=1 -tags "test_unit test_integration" ./...passes on macOS.Also ran the daemon with this on macOS against the same episode: resume at 1h51m, then seeks to 2h22m, 33m and 1h31m from the phone all loaded within a second and played. The CDN didn't stall in that run, so the retry path itself is only covered by the tests above.