New aioredis version detection appears to be malfunctioning

[kevburnsjr]

Description Our build broke today.

No module named 'aioredis.commands'
Traceback (most recent call last):
File "/usr/local/bin/celery", line 8, in <module>

# ... 

File /usr/local/lib/python3.9/site-packages/aioredis/lock.py, line 160, in __aenter__
File /usr/local/lib/python3.9/site-packages/aioredis/lock.py, line 203, in acquire
File /usr/local/lib/python3.9/site-packages/aioredis/lock.py, line 219, in do_acquire
File /usr/local/lib/python3.9/site-packages/newrelic/hooks/datastore_aioredis.py, line 73, in _nr_wrapper_AioRedis_method_

Expected Behavior Newrelic correctly detects aioredis version and does not break

Steps to Reproduce We were pinned to latest. Our build broke without any changes.

Your Environment We have aioredis 2.0.1 installed, but newrelic is taking us down the 1.x codepath. https://github.com/newrelic/newrelic-python-agent/pull/633/files#diff-a7534fe24118f1935337ec79840cf626dbf1b8c257675dfaed0441ab6af98283R73

Additional context Silently defaulting to aioredis version 0.0.0 when aioredis version resolution fails does not seem like desired behavior. We reverted to 8.2.0.181 and the build was fixed.

[rrjjvv]

I just hit this as well:

• python 3.10 + aioredis 2.0.1 + newrelic 8.0.0.179 => good
• python 3.10 + aioredis 2.0.1 + newrelic 8.2.1 => same trace as the reporter

We had other package updates as well, so I can't say with 100% certainty that it was the newrelic update (but seems very likely). Tomorrow I can rollback newrelic (only) to help validate that it alone was the cause.

[TimPansino]

That's really odd, I looked at the repo and definitely see a version attribute on v2.0.1. I'll see if I can track down why it's acting up, it could be an import ordering issue. Thanks for reporting this.

[TimPansino]

It was in fact import ordering and will be fixed in the next release.

[rrjjvv]

To follow up on my "me-too" report, downgrading to my original working version (8.0.0.179) did not work as I expected (but a different failure obviously). Presumably some other library upgrade is changing the behavior. But the nature of the error suggests that it's exactly what 8.2.1 was supposed to fix (instrumenting of transactions), so I'll look forward to that release!

Edit: ~I pointed my build at the branch with the fix, and everything is working again.~ I spoke too soon; it worked because the agent was disabled. That branch/commit does fix the original reported issue, but I still get an error similar to (but not exactly the same) as my new 8.0.0.179 issue. (I'll create a new issue for it if it's not already reported.)