When _ensure_thread() fails or _flusher is None, the code returns at line 66 after setting self._active.flag = True at line 63, but before entering the try block. This bypasses the finally clause that resets the flag. Once this path is taken, the flag remains True permanently for that thread, causing all subsequent add() calls from the same thread to bail out early at line 60-61. This will result in silent span data loss.

Also found at:

• sentry_sdk/_batcher.py:117-122

The flush() method unconditionally sets self._active.flag = True and resets it to False in the finally block, without first checking if the flag was already set. If flush() is called while _flush_loop() is running on the same thread (which permanently sets _active.flag = True), the finally block will incorrectly reset the flag to False, defeating the deadlock protection. This could allow a subsequent add() call to proceed and attempt to acquire locks that are already held.

When _ensure_thread() returns False or _flusher is None at lines 65-66, the method returns without clearing self._active.flag. Since the flag is set at line 63 before the try block that contains the finally to reset it, this early return path leaves the flag permanently True for the current thread. All subsequent add() calls from that thread will be silently discarded. The base class _batcher.py correctly places this check inside the try block (lines 94-96), ensuring the finally always runs.