-
Notifications
You must be signed in to change notification settings - Fork 133
Description
Sporadic 'NoneType' object has no attribute 'request' error from telemetry — usage question
Summary
We're seeing sporadic errors logged from what appears to be the telemetry subsystem. Queries complete successfully, but we'd like to understand if we're missing a recommended usage pattern or if this is a known issue.
Environment
- databricks-sql-connector version: 4.2.4
- Python version: 3.13
- OS: Linux (Ubuntu)
- pyarrow installed: No
Error Message
ERROR:databricks.sql.common.unified_http_client:HTTP request error: 'NoneType' object has no attribute 'request'
Frequency: Sporadic, timing-dependent
Impact: Non-fatal (queries complete successfully)
Our Usage Pattern
We're using short-lived connections with the context manager:
with sql.connect(
server_hostname=host,
http_path=http_path,
access_token=token,
) as connection:
with connection.cursor() as cursor:
cursor.execute(query)
return cursor.fetchall()Our Investigation
We traced through the code and believe the error originates from telemetry, since:
- We don't have pyarrow installed (Cloud Fetch disabled)
- We're not using staging operations
- Thrift RPC uses its own connection pools, not
UnifiedHttpClient - Telemetry is the only remaining
UnifiedHttpClientconsumer in our setup
We noticed that TelemetryClient.close() flushes events but doesn't close _http_client, and wondered if there might be a race condition when async telemetry tasks are still in-flight after the connection closes.
Questions
-
Is there a recommended pattern for short-lived connections that avoids this? For example, should we be keeping connections open longer, or using a connection pool?
-
Is disabling telemetry the intended workaround? We've confirmed that
enable_telemetry=Falseeliminates the error, but wanted to check if this is the right approach or if we're masking an underlying usage issue. -
Should
TelemetryClient.close()be closing_http_client? If this is indeed a bug, we're happy to submit a PR — just want to confirm we're understanding the intended lifecycle correctly.
Workaround (current)
with sql.connect(
server_hostname=host,
http_path=http_path,
access_token=token,
enable_telemetry=False,
) as connection:
...Thanks for any guidance!