Skip to content

Sporadic 'NoneType' object has no attribute 'request' error from telemetry — usage question #731

@rodcochran

Description

@rodcochran

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!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions