[pcbeingused333]

💡 Motivation and Context

The generation wrappers (call_llm_and_track_usage and its async twin) and the Gemini embedding outcome read the HTTP status of a failed call from the exception's status_code, which OpenAI and Anthropic errors have. google-genai's APIError (ClientError and ServerError) keeps the status in code, so every failed Gemini call was captured with $ai_http_status: 0, including 429 and 503 responses.

A small helper, _get_http_status, now reads status_code and, when it is missing, code; a code outside the HTTP range (a gRPC code, for example) still counts as no status, and errors without either give 0 as before. The two wrappers and the Gemini embedding outcome use it.

💚 How did you test it?

• New posthog/test/ai/test_http_status.py: the helper on status_code, code, an out-of-range or non-integer code and a plain exception; real google.genai.errors.ClientError (429) and ServerError (503) through the sync wrapper, and a ClientError through the async one; and an error with status_code through the sync wrapper to show it is unchanged. The three google-genai cases fail on main (status 0) and pass with the change.
• posthog/test/ai/gemini and posthog/test/ai/test_capture_contract.py with the new test: 135 passed, 5 skipped.

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• I updated the docs if needed. (n/a)
• No breaking change or entry added to the changelog.

If releasing new changes

• Ran sampo add to generate a changeset file (added .sampo/changesets/gemini-error-http-status.md in the same format)

🤖 Agent context

Autonomy: Fully autonomous

• The bug was found and the fix, tests and description were written by Claude Code; the diff and the explanation were reviewed before submitting.