Gemini API 備用金鑰：限制故障轉移嘗試次數

A configured backup credential often remains unused when application logic only switches keys after a quota response, allowing a temporary service failure to skip an available recovery path.

Quick solution:
Configure your fallback wrapper to catch HTTP 429, 500, 502, 503, and 504 responses before cycling to the next available credential slot.

class BoundedFailoverClient:
    def __init__(self, credentials):
        self.credentials = credentials
        self.current_index = 0

    def execute(self, request_payload):
        attempts = 0
        while attempts < len(self.credentials):
            try:
                response = self._send(self.credentials[self.current_index], request_payload)
                if response.status_code in [429, 500, 502, 503, 504]:
                    raise TransientError(f"Status {response.status_code}")
                return response
            except TransientError:
                attempts += 1
                self.current_index = (self.current_index + 1) % len(self.credentials)
        raise AllProvidersFailedError("All backup credentials exhausted.")

Prerequisites include maintaining separate project credentials and ensuring request errors remain terminal instead of triggering retries.

Which Response Classes May Use the Backup Chain?

The fallback chain should only engage for specific status codes that indicate capacity or availability issues rather than client-side malformations. Specifically, HTTP 429 (Too Many Requests), 500 (Internal Server Error), 502 (Bad Gateway), 503 (Service Unavailable), and 504 (Gateway Timeout) are eligible to trigger the backup chain as detailed in the Gemini API Troubleshooting Guide. Client-side request errors such as 400 Bad Request or 422 Unprocessable Entity must remain terminal and fail fast, similar to how developers handle invalid payloads when they debug http 422 validation errors safely without triggering credential rotation.

Why Separate Projects Do Not Guarantee Recovery from a Service Outage

Isolating API keys across different Google Cloud or developer projects helps distribute quota limits, but it does not protect your application from a regional or global provider outage. If the underlying API infrastructure experiences a service disruption, secondary project credentials will encounter the same HTTP 503 or 504 errors. Developers must distinguish between project quota exhaustion, which is successfully mitigated by key rotation, and upstream availability failures where all projects are simultaneously impacted.

How Tests Prove One Bounded Chain Per Credential and No Secret Leakage

Unit tests must verify that the failover mechanism iterates through each configured key exactly once per request budget and never exposes sensitive tokens in error logs or exception messages. A proper test suite mocks the transport layer to return alternating 503 and 200 responses, asserting that the client successfully retries with the secondary key without printing the raw API secret to standard output.

What Should Happen When All Providers Fail Without Weakening Publication Review?

When every configured credential in the chain exhausts its retry budget, the client must raise a terminal exception and halt execution rather than looping indefinitely. This strict boundary preserves publication review standards by ensuring that persistent failures surface immediately to monitoring systems instead of masking underlying infrastructure degradation.

Execution Checklist

• Verify that terminal request errors immediately abort the execution loop.
• Confirm that HTTP 429, 500, 502, 503, and 504 status codes trigger the backup key rotation.
• Assert that secret tokens are scrubbed from all exception strings and log outputs.
• Ensure the total retry count matches the number of available credentials in your pool.