ApiClient.__del__ triggers shutdown-time exception in influxdb-client 1.50.0

[stefanbie1]

Specifications

• Python: 3.11.x
• Package: influxdb-client 1.50.0
• OS: Linux

Code sample to reproduce problem

from influxdb_client import InfluxDBClient

client = InfluxDBClient(url="http://localhost:8086", token="token", org="org")
client.close()
# app exits normally here

or in a slightly more explicit shutdown flow:

from influxdb_client import InfluxDBClient

c = InfluxDBClient(url="http://localhost:8086", token="token", org="org")
c.close()
del c
import gc
gc.collect()

The exact warning may appear at interpreter exit, depending on timing and GC state.

Expected behavior

The library should not emit shutdown-time exceptions during normal program exit after close() has been called. The finalizer should be safe when the interpreter is already tearing down objects and modules.

Actual behavior

The destructor path triggers late in shutdown and emits Exception ignored... warnings, which are noisy and can hide real application errors in CI logs.

Additional info

What I observed

The warning is emitted even after the application calls close() correctly. The destructor appears to run late, during interpreter shutdown, when module-level references are already partially torn down.

The relevant path is effectively:

InfluxDBClient.close() ->
    api_client.close() ->
    ApiClient.__del__() ->
        _signout()

and ApiClient.__del__ is invoked during interpreter shutdown, after the library has already started clearing state.

Root cause

The issue is in the library destructor rather than the caller application code:

• ApiClient.__del__ does not guard against interpreter shutdown
• it calls _signout() without verifying that the underlying HTTP/session state still exists
• at shutdown time, globals and object members may already be None or already removed
• that leads to Exception ignored in: <function ApiClient.__del__ ...> warnings even though the app may have completed successfully

This is a classic destructor-safety issue: library cleanup should not run unconditionally in Python finalization when module state is already being torn down.

Evidence

Code inspection of the installed library shows the destructor path is roughly:

class ApiClient:
    def __del__(self):
        try:
            self._signout()
        except Exception:
            pass

and _signout() accesses HTTP/session state that may already be cleared during interpreter shutdown.

The app-side mitigation we tried was to explicitly close and clear the client object before exit; however, the warning remains because it is triggered from inside the library finalizer and not from the application's own logic.

Proposed fix

The library should guard shutdown-time finalizers so they do nothing if Python is already tearing down the interpreter or if the necessary member state is no longer available.

Examples of safe patterns:

def __del__(self):
    try:
        if getattr(self, "_http", None) is not None:
            self._signout()
    except Exception:
        pass

or equivalent checks using threading / interpreter-state guard logic.

It is also advisable to make _signout() resilient to partially initialized state and to avoid assuming members remain valid during finalization.

Impact

This is a library correctness issue with noisy shutdown warnings that may confuse users and CI systems. It is especially problematic because it can look like the application failed even when the app completed its work normally.