{"version":"2.1.267","anchor":"retry-logic-now-treats-stream-idle-timeout-like-other-transi","canonical_anchor":"retry-logic-now-treats-stream-idle-timeout-like-other-transi","heading":"Retry logic now treats stream_idle_timeout like other transient errors","tier":"notice","area":"Elsewhere","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.267\/e\/retry-logic-now-treats-stream-idle-timeout-like-other-transi","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.267","markdown":"### Retry logic now treats stream_idle_timeout like other transient errors\n\nRetries now treat stream_idle_timeout the same as other transient network errors\n\n**What**\n\nThe 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.\n\n**Why**\n\nA 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.\n\n- Area: Elsewhere\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5"}