s3/transfermanager: avoid double-closing concurrentReader channel after read errors

[islishude]

Summary

Fix a panic in transfermanager concurrentReader when Read is called again after a non-EOF error.

Problem

When concurrentReader.Read encounters a non-EOF error, it closes r.ch to unblock the internal reader goroutine. If the caller invokes Read again, the method previously continued through the same cleanup path and attempted to close r.ch a second time, causing this panic: panic: close of closed channel

Changes

Return the stored non-EOF error immediately on subsequent Read calls
Guard r.ch close with sync.Once so channel shutdown is idempotent
Add a regression test covering repeated Read calls after a download error

Test

go test ./... in feature/s3/transfermanager

[Copilot]

Pull request overview

Fixes a panic in transfermanager’s concurrentReader when Read is invoked again after a previous non-EOF read error, by making channel shutdown and error re-reads idempotent.

Changes:

• Return the stored non-EOF error immediately on subsequent Read calls.
• Guard r.ch shutdown with sync.Once to prevent double-close panics.
• Add a regression test for repeated Read calls after a download error.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
feature/s3/transfermanager/concurrent_reader.go	Prevents double-closing r.ch and short-circuits repeated reads after non-EOF errors.
feature/s3/transfermanager/concurrent_reader_test.go	Adds a regression test covering repeated Read calls after an injected range-download error.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[islishude]

Hi there, could you team please take a look? and please also #3388

[wty-Bryant]

sorry, dealing with some other feature parity this week, will look into those 2 PRs recently