Two production-flavor tests have been red on every PR against next since around 2026-05-09 and are blocking unrelated work:
tests/unit/test_common/test_composio_client.py::TestComposioAPIClient::test_get_auth_data[production]tests/unit/test_common/test_validators.py::TestValidateConnectionId::test_valid_connection_id_passes[production]Same two tests, same connection ID (ca_b4n5mE5GC0qh), same 403 Forbidden on GET /admin/connections/ca_b4n5mE5GC0qh — visible on at least PR #1413 (no auth-code changes) and PR #1417 (prompt-only changes), so this is not a regression introduced by either PR.
Root cause is environmental, not code. CI's COMPOSIO_ADMIN_TOKEN can LIST gmail connections (so get_connection_id returns ca_b4n5mE5GC0qh) but gets 403 Forbidden on the per-connection read endpoint. The token has list permission but not per-connection read for the dynamically-selected default connection.
These tests already pytest.skip when env vars are missing. Extend that same pattern: skip with a clear "token lacks per-connection read" message when the admin token returns 403.
get_gmail_connection_id in both files: catch requests.exceptions.HTTPError with status 403 from client.get_connection_id("gmail") and skip.TestComposioAPIClient::test_get_auth_data: wrap the client.get_auth_data(...) call; skip on 403 from the per-connection read.TestValidateConnectionId::test_valid_connection_id_passes: wrap the validate_connection_id(...) call; validate_connection_id wraps the HTTPError in a ValueError, so we check e.__cause__.The skip is bypassed by setting GMAIL_CONNECTION_ID / GMAIL_CONNECTION_ID_STAGING to a connection the token can read. Real auth-data regressions will still surface when the token is properly scoped.
uvx ruff check and uvx ruff format --check clean on both files.COMPOSIO_ADMIN_TOKEN to one that owns the gmail connection, set GMAIL_CONNECTION_ID in the CI workflow to a token-owned connection, or change get_connection_id to filter for connections the caller can read.