fix(streaming): clamp a Range end past EOF instead of marking the file corrupted - #937
Merged
Merged
Conversation
…e corrupted The WebDAV adapter hands the raw Range header to the file via context and getRequestRange parsed it without knowing the file size, so a legal "bytes=N-<past EOF>" request reached createUsenetReader unclamped. findSegmentForOffset(end) returned -1 for the out-of-range end, the lazy segment range came back empty, and that emptiness was treated as corrupt metadata: the file was marked FILE_STATUS_CORRUPTED and vanished from WebDAV. The parsed end is now clamped to FileSize-1, and createUsenetReader returns io.EOF for a start at or past EOF and clamps its end, so only a genuinely broken segment index can still produce the corruption verdict.
4 tasks
Merged
6 tasks
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.
Summary
Range: bytes=N-<past EOF>request (start inside the file, end beyond it — RFC 9110 §14.1.2 says to clamp) reachedcreateUsenetReaderunclamped: the WebDAV adapter passes the raw header via context andgetRequestRangeparsed it without knowing the file size.findSegmentForOffset(end)returned -1 for the out-of-range end, the lazy segment range came back empty, and that emptiness was treated as corrupt metadata:FILE_STATUS_CORRUPTED, and the healthy file then 404'd on WebDAV. Reproduced against a real provider with onecurl -r 15000000000-15268435455on a 15,076,905,867-byte file.FileSize-1ingetRequestRange; increateUsenetReaderreturnio.EOFforstart >= FileSizeand clampend. A genuinely broken segment index still produces the corruption verdict.Test plan
TestRangeEndPastEOFIsClampedNotCorrupted— failed before the fix with the production log line, passes after; served bytes equal the file tail, no health record writtenTestRangeStartAtOrPastEOFIsEOFNotCorrupted—Readreturns0, io.EOF, no corruptiongo vet,go test -race ./internal/nzbfilesystem/... ./internal/importer/filesystem/...,go build ./cmd/altmount