Deadlock in LogBatcher when ResourceWarning emitted during flush (enable_logs=True)

[ndmanvar]

How do you use Sentry?

Sentry Saas (sentry.io)

Version

2.54.0

Steps to Reproduce

1. Initialize sentry-sdk with enable_logs=True
2. Enable warning capture: logging.captureWarnings(True)
3. Set warnings.filterwarnings("always", category=ResourceWarning)
4. Pre-fill the log batcher with ~2000 log messages
5. Trigger a flush on a background thread
6. During flush, cause a ResourceWarning to be emitted (e.g. via GC callback)
   • The warning is routed through stdlib logging → Sentry logging integration → LogBatcher.add()
   • LogBatcher.add() attempts to acquire _log_batcher._lock
   • flush() already holds _lock on the same thread → self-deadlock
7. Attempt to log from another thread — it will hang indefinitely

Repro script is attached (reproduces reliably on Python 3.11, sentry-sdk 2.54.0).

repro.py

Expected Result

Flushing logs should not deadlock when a warning is emitted on the flush thread.
Either:

• _log_batcher._lock should be a threading.RLock (reentrant lock) to allow
  re-entry on the same thread, or
• The logging integration should not attempt to add to the batcher while a flush
  is already in progress on the same thread.

Currently, the non-reentrant lock causes the flush thread to self-deadlock,
which then blocks all other threads that attempt to log — freezing the entire application.

Actual Result

Application freezes indefinitely; flush thread self-deadlocks, blocking all subsequent logging across all threads.

[linear-code]

PY-2144