From b538cc195d0df87e5cdbad20eacea74d177b90d8 Mon Sep 17 00:00:00 2001 From: ygd58 Date: Mon, 20 Apr 2026 12:23:45 +0200 Subject: [PATCH] fix(retry): prevent attempt counter reset after primary transport recovery MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When _try_recover_primary_transport() succeeded, retry_count was reset to 0 — causing the attempt counter shown to the user to restart from (1/3) after already showing (1/3), (2/3). The sequence appeared as: (attempt 1/3) -> (attempt 2/3) -> (attempt 1/3) -> (attempt 2/3) instead of the expected monotonically increasing sequence. Fix: instead of resetting retry_count to 0, increment max_retries by 1. This grants the rebuilt client exactly one extra attempt while keeping the displayed counter monotonic and meaningful. Fixes #12956 --- run_agent.py | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/run_agent.py b/run_agent.py index bb1c8b899..08164a2bf 100644 --- a/run_agent.py +++ b/run_agent.py @@ -10199,7 +10199,12 @@ class AIAgent: api_error, retry_count=retry_count, max_retries=max_retries, ): primary_recovery_attempted = True - retry_count = 0 + # Do NOT reset retry_count to 0 — that causes the + # attempt counter to show (1/3), (2/3), (1/3), (2/3) + # instead of a monotonically increasing sequence. + # Grant one extra attempt beyond max_retries so the + # rebuilt client gets exactly one shot (issue #12956). + max_retries += 1 continue # Try fallback before giving up entirely self._emit_status(f"⚠️ Max retries ({max_retries}) exhausted — trying fallback...")