Using RLock (instead of Lock) to prevent deadlocks when using sentry and ddtrace at the same time.

[antonpirker]

Refs #3753

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 79.57%. Comparing base (5dcda1d) to head (02380b7).

✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #4159   +/-   ##
=======================================
  Coverage   79.57%   79.57%           
=======================================
  Files         141      141           
  Lines       15711    15711           
  Branches     2671     2671           
=======================================
  Hits        12502    12502           
  Misses       2367     2367           
  Partials      842      842           

Files with missing lines	Coverage Δ
sentry_sdk/worker.py	80.41% <100.00%> (ø)

[sl0thentr0py]

what is the actual problem and how does this fix it?

[antonpirker]

This is an experiment.

The problem described in #3753 is roughly like this:

• DataDog is monitoring lock operations
• Sentry's worker thread needs to acquire a lock
• When lock operations occur, DataDog tries to log information
• Logging triggers Sentry's logging integration
• Sentry tries to capture this event
• Capturing an event requires Sentry's worker thread
• The worker thread needs to acquire a lock...

By changing to RLock the given reproduction does not run into a deadlock anymore. But I am not 100% sure that this does not lead to other problems. (I think it does not, but I am not sure)

[antonpirker]

I wanted to see if any of our test start failing if using RLock.