[BUG]: wrapt 2.0 release broke application (mitigation available)

[c-warwick]

Tracer Version(s)

2.20.0

Python Version(s)

3.10.9

Pip Version(s)

22.3.1

Bug Report

We host a django app served by gunicorn using the following command

exec ddtrace-run gunicorn \
  --preload -w 3 \
  --log-level debug \
  -p /run/gunicorn_sr.pid \
  -b 0.0.0.0:9000 \
  --timeout=60 \
  --max-requests=200 \
  --forwarded-allow-ips 127.0.0.1 \
  --chdir "$(pwd)" \
  --config "$(pwd)/<app-name>/gunicorn_config.py" \
  <app-name>.wsgi:application

it would successfully do gunicorn pre/post fork work then just flat out not hand over control to the django site.

Pinning wrapt to 1.17.3 was the fix.

This failure was very silent with no error logging of any kind - we only found the issue by comparing good and bad images to find wrapt being the only diff.

Reproduction Code

No response

Error Logs

No response

Libraries in Use

No response

Operating System

python:3.10-slim (debian)

[brettlangdon]

@c-warwick thanks for opening this issue.

We have fixed this in 3.15.1 and 3.16.2, we do not have a release ready for 2.x release line.

For people who cannot upgrade to 3.15.1 or 3.16.2 we are asking them to also pin wrapt to wrapt>=1,<2.

Aside: The 2.x release line will go EOL at the end of this month, and 4.x will be released before EOY. We always recommend people upgrading to the latest available versions when possible.

[c-warwick]

Thank you! We'll get on the train - will look at jump from 2-3* (I read 4.x EOM but it's EOY)

[brettlangdon]

Thank you! We'll get on the train - will look at jump from 2-4

well, 4.0 isn't released yet, but I'd try 3.16.2 if you can

made the comment mostly to help show the age of 2.x 😅

[lattwood]

Can you cut a CVE as this impacts the Availability aspect of the CIA (Confidentiality, Integrity, Availability) triad?

This would dramatically help folks with remediation through automated tools, too.

[taylorhughes]

This also broke our release today with an added ~6 hours of full shots-in-the-dark debugging. Pretty tough to identify that this was due to a downstream dependency of a package we hadn't updated. Worth advertising pretty loudly to anyone currently using an affected ddtrace version with django.