Determine this is the right repository
Summary of the feature request
When opentelemetry-api is installed and a global tracer provider is configured, google-cloud-bigquery automatically wraps every BQ call in a span (BigQuery.job.begin, BigQuery.getQueryResults, etc.) via opentelemetry_tracing.create_span. There is no documented way to opt out, so projects that want OTel for their own code but not for BQ end up with their traces drowned in BQ spans.
Desired code experience
Any of the following would be a supported, public way to disable the library's built-in tracing:
# Option A — env var
# GOOGLE_CLOUD_BIGQUERY_DISABLE_TRACING=1
# Option B — constructor argument
from google.cloud import bigquery
client = bigquery.Client(enable_tracing=False)
# Option C — honor the OTel SDK's standard opt-out
# OTEL_PYTHON_DISABLED_INSTRUMENTATIONS=google-cloud-bigquery
Happy to send a PR if there is a preferred approach.
Expected results
With any of the above set, BQ client calls should not emit spans, even though opentelemetry-api is installed and a tracer provider is configured for the rest of the application.
API client name and version
google-cloud-bigquery v3.38.0
Use case
We use Logfire (OpenTelemetry-based) to trace AI-agent runs and outbound HTTP. Once the tracer provider is configured, every BQ call also emits a span, which drowns out the agent traces we actually care about. We want OTel for our own code, but not for BQ.
Additional context
The only working workaround today is mutating the module-level HAS_OPENTELEMETRY flag before any BQ call:
import google.cloud.bigquery.opentelemetry_tracing as _bq_otel
_bq_otel.HAS_OPENTELEMETRY = False
This works because create_span reads the global at call time and client.py only imports create_span, not the flag itself. But it relies on a non-public attribute and could silently regress on any internal refactor. Uninstalling opentelemetry-api is not viable when the rest of the application depends on it.
Source reference: packages/google-cloud-bigquery/google/cloud/bigquery/opentelemetry_tracing.py — the HAS_OPENTELEMETRY flag and create_span function.
Determine this is the right repository
Summary of the feature request
When
opentelemetry-apiis installed and a global tracer provider is configured,google-cloud-bigqueryautomatically wraps every BQ call in a span (BigQuery.job.begin,BigQuery.getQueryResults, etc.) viaopentelemetry_tracing.create_span. There is no documented way to opt out, so projects that want OTel for their own code but not for BQ end up with their traces drowned in BQ spans.Desired code experience
Any of the following would be a supported, public way to disable the library's built-in tracing:
Happy to send a PR if there is a preferred approach.
Expected results
With any of the above set, BQ client calls should not emit spans, even though
opentelemetry-apiis installed and a tracer provider is configured for the rest of the application.API client name and version
google-cloud-bigquery v3.38.0
Use case
We use Logfire (OpenTelemetry-based) to trace AI-agent runs and outbound HTTP. Once the tracer provider is configured, every BQ call also emits a span, which drowns out the agent traces we actually care about. We want OTel for our own code, but not for BQ.
Additional context
The only working workaround today is mutating the module-level
HAS_OPENTELEMETRYflag before any BQ call:This works because
create_spanreads the global at call time andclient.pyonly importscreate_span, not the flag itself. But it relies on a non-public attribute and could silently regress on any internal refactor. Uninstallingopentelemetry-apiis not viable when the rest of the application depends on it.Source reference:
packages/google-cloud-bigquery/google/cloud/bigquery/opentelemetry_tracing.py— theHAS_OPENTELEMETRYflag andcreate_spanfunction.