fixup! STF-322: Document transport-failure retry in README and CHANGELOG

Author: oschwald

CHANGELOG.md

@@ -7,10 +7,12 @@ CHANGELOG
 * Added `FAT_ZEBRA` to the `Payment.Processor` enum.
 * Added `CLEAR` to the `TransactionReport.Tag` enum for use with the Report
   Transaction API.
-* Added `WebServiceClient.Builder.maxRetries(int)` to configure transport-failure
-  retry behavior. Defaults to 1 (one retry on connection reset, broken pipe,
-  or connect timeout). Set to 0 to disable. Request-phase timeouts and HTTP
-  4xx/5xx responses are never retried.
+* Added `WebServiceClient.Builder.maxRetries(int)` to configure transport-
+  failure retry behavior. Defaults to 1 (one retry on transient transport
+  errors such as connection reset, broken pipe, EOF, or closed channel).
+  Set to 0 to disable. `HttpTimeoutException` (covering both request-phase
+  and connect-phase timeouts), `InterruptedIOException`, and HTTP 4xx/5xx
+  responses are never retried.
 
 4.2.0 (2026-02-26)
 ------------------

README.md

@@ -115,19 +115,23 @@ See the API documentation for more details.
 `WebServiceClient` is thread-safe and reuses a pooled `HttpClient` across
 requests. Idle connections in the pool can be silently closed by load
 balancers or other intermediaries. When the next request reuses one of these
-half-closed connections, the JDK reports the failure as a `Connection reset`
-(or `Broken pipe`) `IOException`.
-
-To smooth over these intermittent transport failures, the SDK retries once by
-default. The retry covers:
-
-* `SocketException` with message `Connection reset` or `Broken pipe`,
-* `ConnectException`,
-* `HttpConnectTimeoutException`.
-
-Retries are **not** applied to request-phase timeouts (`HttpTimeoutException`)
-or to HTTP 4xx / 5xx responses. POST bodies are replayable, so retried
-requests are byte-identical to the original.
+half-closed connections, the JDK reports the failure as a `Connection reset`,
+`Broken pipe`, or related transport `IOException`.
+
+To smooth over these intermittent transport failures, the SDK retries once
+by default. Any transport-level `IOException` raised by the underlying HTTP
+send is retried, with two exceptions:
+
+* `HttpTimeoutException` — a request-phase timeout. Connect-phase timeouts
+  (`HttpConnectTimeoutException`) are also excluded because they extend
+  `HttpTimeoutException`. The SDK honors the timeouts you configure.
+* `InterruptedIOException` — the calling thread was interrupted; the SDK
+  honors the cancellation rather than override it.
+
+HTTP 4xx and 5xx responses are not retried — they are returned as
+`HttpResponse` objects (not `IOException`s) and surfaced through the existing
+exception hierarchy. POST bodies are replayable, so retried requests are
+byte-identical to the original.
 
 You can change the retry budget via the builder: