You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Gate BigQuery classification on an explicit error wrapper (#4309)
The previous classifier change matched bare *googleapi.Error and
labelled every match as bigquery. But *googleapi.Error is the shared Go
error type for any HTTP-level Google API failure — GCS-outside-BQ, KMS,
Pub/Sub, etc. all surface it. A stray googleapi error from anywhere in
the codebase would be misattributed to BigQuery, polluting per-source
telemetry.
Introduce exceptions.BigQueryError as an explicit wrapper that callers
in the BigQuery connector use to mark "this error came from a BQ code
path", and gate BigQuery classification on its presence.
Inside the gate, both SDK error types are inspected because they come
from different paths and never co-occur:
- *googleapi.Error (HTTP-level, integer Code) — from API call failures
like Run, Wait, Metadata, Create, Delete, GCS iterator Next. 401/403/
404 map to connectivity.
- *bigquery.Error (job-level, string Reason like "invalidQuery" or
"accessDenied") — produced by JobStatus.Err() when a job is accepted by
the API but fails during execution. The Reason is surfaced as the code
for diagnostic clarity; we don't classify individual Reasons yet, so the
class falls through to ErrorOther with BQ source.
Tests updated to wrap inputs in BigQueryError; new negative test asserts
that an unwrapped *googleapi.Error from outside the BQ connector now
falls through to ErrorSourceOther rather than being mislabelled.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
0 commit comments