fix(retry): prevent attempt counter reset after primary transport recovery

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
This commit is contained in:
ygd58 2026-04-20 12:23:45 +02:00
parent bd7e272c1f
commit b538cc195d
No known key found for this signature in database
GPG key ID: 82B49AE8D5B28600

View file

@ -10199,7 +10199,12 @@ class AIAgent:
api_error, retry_count=retry_count, max_retries=max_retries, api_error, retry_count=retry_count, max_retries=max_retries,
): ):
primary_recovery_attempted = True 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 continue
# Try fallback before giving up entirely # Try fallback before giving up entirely
self._emit_status(f"⚠️ Max retries ({max_retries}) exhausted — trying fallback...") self._emit_status(f"⚠️ Max retries ({max_retries}) exhausted — trying fallback...")