ddtrace 1.10 triggers AttributeError in redis.Client.__del__ at process exit

[noirbee]

Summary of problem

Following an update to ddtrace 2.10 (and up, to v2.14.1), we've started encountering the issue described in redis/redis-py#3014 . At interpreter shutdown, processes with redis connections (typically through rq) encounter an error in redis.Client.__del__ / redis.ConnectionPool._checkpid():

KeyboardInterrupt
Exception ignored in: <function Redis.__del__ at 0x7f6261124220>
Traceback (most recent call last):
  File "/tmp/venv/lib/python3.12/site-packages/redis/client.py", line 520, in __del__
  File "/tmp/venv/lib/python3.12/site-packages/redis/client.py", line 535, in close
  File "/tmp/venv/lib/python3.12/site-packages/redis/connection.py", line 1498, in disconnect
  File "/tmp/venv/lib/python3.12/site-packages/redis/connection.py", line 1399, in _checkpid
AttributeError: 'NoneType' object has no attribute 'getpid'

(issue happens with redis v5.0.4 through 5.1; probably for all versions which include redis/redis-py@012f7cf , as pointed out in the redis-py isue)

This happens by merely importing ddtrace, without even calling e.g. patch_all().

I've opened redis/redis-py#3397 on the redis client side, but without ddtrace (or with ddtrace < 2.10) this does not happen, so I suspect there may still be an issue with ddtrace (including with other libraries in the future).

git bisect tells me 66b96e9 is the culprit, though it's not obvious to me why (the ddtrace.module.internal changes ?).

Which version of dd-trace-py are you using?

Seen from 2.10 to 2.14.1

Which version of pip are you using?

24.2

Which libraries and their versions are you using?

`pip freeze`

attrs==24.2.0 azure-common==1.1.28 azure-core==1.31.0 azure-eventhub==5.12.1 azure-eventhub-checkpointstoreblob==1.1.4 azure-identity==1.18.0 azure-mgmt-core==1.4.0 azure-mgmt-eventhub==11.1.0 bytecode==0.15.1 cattrs==24.1.2 certifi==2024.8.30 cffi==1.17.1 charset-normalizer==3.3.2 click==8.1.7 colorama==0.4.6 cryptography==43.0.1 datadog==0.50.1 ddsketch==3.0.1 ddtrace==2.10.0 Deprecated==1.2.14 envier==0.5.2 Flask==2.2.5 idna==3.10 importlib_metadata==8.4.0 isodate==0.6.1 itsdangerous==2.2.0 Jinja2==3.1.4 JSON-log-formatter==1.0 Markdown==3.7 MarkupSafe==2.1.5 marshmallow==3.22.0 marshmallow_dataclass==8.7.1 msal==1.31.0 msal-extensions==1.2.0 msrest==0.7.1 mypy-extensions==1.0.0 oauthlib==3.2.2 opentelemetry-api==1.27.0 packaging==23.2 portalocker==2.10.1 protobuf==5.28.2 pycparser==2.22 PyJWT==2.9.0 PyYAML==6.0.2 redis==5.0.8 requests==2.32.3 requests-oauthlib==2.0.0 rq==1.16.2 setuptools==75.1.0 six==1.16.0 tenacity==8.5.0 typeguard==4.3.0 typing-inspect==0.9.0 typing_extensions==4.12.2 urllib3==2.2.3 uv==0.4.17 Werkzeug==2.2.3 wrapt==1.16.0 xmltodict==0.13.0 zipp==3.20.2

How can we reproduce your problem?

I cannot provide minimal code to reproduce the problem; a simple Python file opening a connection to redis does not trigger it. I suspect this happens due to the number of modules loaded when running our code (both our own, and the libraries that ddtrace monkey-patches).

What is the result that you get?

Stacktrace on stderr, which ends up polluting our logs with undue errors.

Moreover, since this done by the interpreter top-level exception handler, the logging configuration is not used in this case. This ends up sending multiple lines to stderr (instead of a single JSON structured log line).

What is the result that you expected?

No error at process shutdown.