Summary

In agent/error_classifier.py, the _classify_by_message() function (the fallback path when no HTTP status code is available) marks auth errors as retryable=True. This is inconsistent with the _classify_by_status() path which correctly uses retryable=False for 401/403 auth errors.

Location

File: agent/error_classifier.py, inside _classify_by_message() at line ~728:

# Auth patterns
if any(p in error_msg for p in _AUTH_PATTERNS):
    return result_fn(
        FailoverReason.auth,
        retryable=True,   # ← BUG: should be False
        should_rotate_credential=True,
    )

Inconsistency with status-code path

In _classify_by_status(), auth errors (401/403) are correctly non-retryable:

if status_code == 401:
    return result_fn(
        FailoverReason.auth,
        retryable=False,   # ← correct
        should_rotate_credential=True,
    )

Impact

When an API response lacks an HTTP status code but contains an auth-related message (e.g. SDK wraps the error, streaming disconnect, or provider error formats), the classifier returns retryable=True for auth failures. This means:

1. The caller retries with the same invalid credential instead of rotating
2. Creates an unnecessary retry loop before eventually hitting max retries
3. Wastes time and potentially burns rate-limit quota with doomed requests

Fix

Change retryable=True → retryable=False in the auth pattern branch of _classify_by_message(). Auth errors indicate the credential is invalid; retrying with the same key will always fail. The should_rotate_credential=True already signals the correct action.