Catch urllib3 ProtocolError on streamed responses

[jinzhao1994]

Problem

When aws s3 cp --recursive downloads large objects, a single mid-transfer TCP
reset fails the entire file. s3transfer's part-level retry
(num_download_attempts, default 5) never engages.

Production traceback (aws-cli/2.36.5 Python/3.14.6 Linux, ~114 GB across 51
objects, max_concurrent_requests = 32):

File "awscli/s3transfer/tasks.py", line 137, in __call__
File "awscli/s3transfer/tasks.py", line 160, in _execute_main
File "awscli/s3transfer/download.py", line 672, in _main
File "awscli/s3transfer/download.py", line 855, in __next__
File "awscli/s3transfer/utils.py", line 608, in read
File "awscli/botocore/response.py", line 86, in read
File "urllib3/response.py", line 1112, in read
File "urllib3/response.py", line 930, in _error_catcher
urllib3.exceptions.ProtocolError: ("Connection broken: ConnectionResetError(104, 'Connection reset by peer')", ConnectionResetError(104, 'Connection reset by peer'))

In that run, 4 ProtocolErrors mapped 1:1 onto 4 download failed lines — no
retry was attempted for any of them. From the same --debug log:

grep -c 'Retrying exception caught' -> 0
grep -c 'RetriesExceededError'      -> 0
grep -c 'ResponseStreamingError'    -> 0

Note the request-level retry in botocore cannot help here: the reset happens
while streaming the body, long after a 200 response head was received, so the
log shows botocore.retries.standard - Not retrying request. before each
failure.

Root cause

urllib3.exceptions.ProtocolError inherits ProtocolError -> HTTPError -> Exception. It is neither a ConnectionError nor a ResponseStreamingError, so
except S3_RETRYABLE_DOWNLOAD_ERRORS in GetObjectTask._main does not match and
the exception escapes the retry loop entirely.

The v2 branch is missing two upstream fixes:

upstream	what it does	in v1 since	in v2
boto/botocore#2573 (a5e5119b6, 2021-12-10)	wraps URLLib3ProtocolError into a new ResponseStreamingError	botocore 1.23.24	❌
boto/s3transfer#301 (5fc308a11, 2024-03-06)	adds ResponseStreamingError to S3_RETRYABLE_DOWNLOAD_ERRORS	s3transfer 0.10.1	❌

awscli v1 has had both for a while (it currently resolves botocore 1.43.62 /
s3transfer 0.19.2), so v2 is strictly behind v1 on download resilience here.

Both halves are needed — wrapping alone still would not match the retryable
tuple.

Change

• awscli/botocore/exceptions.py: add ResponseStreamingError (verbatim from cloudformation deploy: Use parameter default value only on stack creation #2573).
• awscli/botocore/response.py: StreamingBody.read() wraps URLLib3ProtocolError (verbatim from cloudformation deploy: Use parameter default value only on stack creation #2573).
• awscli/s3transfer/utils.py: add ResponseStreamingError to S3_RETRYABLE_DOWNLOAD_ERRORS (from Fix retrying incomplete downloads with urllib3 2.x boto/s3transfer#301).
• Tests: the unit test from cloudformation deploy: Use parameter default value only on stack creation #2573, plus a GetObjectTask test asserting the
  part-level retry now actually engages and the download completes.

StreamingBody on v2 has no readinto(), so unlike current botocore
develop there is no second call site to guard.

Scope

This does not address why the resets happen — that is a separate network-side
issue. It fixes the amplifier: a transient reset becomes a retryable, recoverable
part failure instead of a whole-file failure.

Testing

• tests/unit — 9392 passed (one pre-existing unrelated failure in
  tests/unit/customizations/history/test_history.py, present on a clean v2).
• tests/functional/s3, tests/functional/s3transfer — 509 passed.
• ruff / ruff-format (pinned 0.4.8, per .pre-commit-config.yaml) clean.
• Both new tests verified to fail without the source change.

---

Generated by AI tools, and reviewed by Sheng Cao.