You'll notice
Retries now treat stream_idle_timeout the same as other transient network errors
What
The logic that decides whether to log and retry an error after a failed request used to recognize connection_error, server_overload, api_timeout, and rate_limit. It now also recognizes stream_idle_timeout, logging "API {type} after retries" and treating it the same way as those other transient errors.
Why
A connection that goes idle mid-stream is now handled like other temporary network hiccups, so it can be retried instead of surfacing immediately as a failure.