Incorrect start offset when range reads are interrupted

[wilson1yan]

Environment details

GCP A100 machines
(unclear about exact software, as this bug was countered internally on Google infra when running on XManager Cloud)

Steps to reproduce

Given a range read of start to end bytes, if the read is interrupted, the code here will make another GET request at the wrong start offset, as it should be self.start + self._bytes_downloaded if self.start is not None. Currently, the downloader will return end + 1 bytes instead of end - start + 1 bytes after resuming from interruption even when start is specified.

The same issue also probably happens here in Downloader.

We encountered this issue when using the google python storage library in the setting where we had thousands of workers doing repeated range reads on the same GCS file. Code would run and return the wrong bytes somewhere 20-60min in. Adding in a fix (see pull request) seemed to resolve the issue.

[andrewsg]

Thanks very much! Looking at this now. I need to add tests so I may work on a separate PR for this issue but I appreciate your fix as well.

[wilson1yan]

Sounds good, feel free to work on a separate PR! Just thought I'd let you all know about the bug.

Please let me know when you end up applying the fix and/or push a new pip release. As right now my project is pip installing from this pull request directly, but would be good to just install an official pypi version thats updated.

[andrewsg]

@wilson1yan This is now being released as v2.7.2. Thanks again.

[wilson1yan]

Awesome, thanks!