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 UnifiedHttpClient consumer 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

1. 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?

2. Is disabling telemetry the intended workaround? We've confirmed that enable_telemetry=False eliminates the error, but wanted to check if this is the right approach or if we're masking an underlying usage issue.

3. 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!