Any transport instrumentation that calls Sentry.metrics.* from within
transport#send_data re-enters MetricEventBuffer#add_item on the same
thread that already holds @Mutex inside send_items, raising:

  ThreadError: deadlock; recursive locking

This includes any non-Yabeda code such as custom transports or other
HTTP instrumentation (see getsentry/repro#46 for a minimal repro using
a ReentrantTransport that calls Sentry.metrics directly from send_data).

Fix: check @mutex.owned? before acquiring in add_item and silently drop
the item when the current thread already holds the lock. This is the
defensive fix at the correct abstraction level and protects all buffers
(MetricEventBuffer, LogEventBuffer) from all callers.

The sentry-yabeda Adapter guard (HTTPTransport.sending?) is retained as
defense-in-depth and avoids constructing a MetricEvent that will be
dropped, but the buffer-level fix is the load-bearing protection.

Refs #2963
Refs getsentry/repro#46

Co-Authored-By: junior <[email protected]>

Co-authored-by: johdax <[email protected]>

…etsentry#2964)

* fix(yabeda): skip Sentry adapter during own HTTP transport sends

MetricEventBuffer uses a non-reentrant Mutex. When HTTP instrumentation
(e.g. yabeda-http_requests, yabeda-rails) observes the outgoing Net::HTTP
call made by HTTPTransport#send_data, it triggers Sentry::Yabeda::Adapter
which calls Sentry.metrics.* -> MetricEventBuffer#add_item on the same
thread that already holds the buffer mutex, raising:

  ThreadError: deadlock; recursive locking

Fix: set a thread-local flag (SENTRY_SENDING_KEY) in HTTPTransport for
the duration of the do_request call and check it in all Adapter#perform_*!
methods, silently skipping metric forwarding for Sentry's own HTTP sends.

Fixes getsentry#2963

Co-Authored-By: junior <[email protected]>

Co-authored-by: neel <[email protected]>

* fix(telemetry): guard add_item against re-entrant mutex acquisition

Any transport instrumentation that calls Sentry.metrics.* from within
transport#send_data re-enters MetricEventBuffer#add_item on the same
thread that already holds @Mutex inside send_items, raising:

  ThreadError: deadlock; recursive locking

This includes any non-Yabeda code such as custom transports or other
HTTP instrumentation (see getsentry/repro#46 for a minimal repro using
a ReentrantTransport that calls Sentry.metrics directly from send_data).

Fix: check @mutex.owned? before acquiring in add_item and silently drop
the item when the current thread already holds the lock. This is the
defensive fix at the correct abstraction level and protects all buffers
(MetricEventBuffer, LogEventBuffer) from all callers.

The sentry-yabeda Adapter guard (HTTPTransport.sending?) is retained as
defense-in-depth and avoids constructing a MetricEvent that will be
dropped, but the buffer-level fix is the load-bearing protection.

Refs getsentry#2963
Refs getsentry/repro#46

Co-Authored-By: junior <[email protected]>

Co-authored-by: johdax <[email protected]>

* test(transport): fix rubocop syntax error in .sending? specs

Replace instance_double with []: nil keyword syntax (invalid in Ruby 2.7
parser) with build_fake_response, consistent with the rest of the spec.

Co-Authored-By: junior <[email protected]>

Co-authored-by: johdax <[email protected]>

* refactor(telemetry): simplify re-entrant deadlock fix to single mutex guard

Remove the thread-local flag layer (HTTPTransport.sending?, with_sentry_sending,
Yabeda adapter sentry_http_sending? checks) in favor of the @mutex.owned? guard
in TelemetryEventBuffer alone. This is simpler, more general, and eliminates
cross-gem coupling. Also add the guard to flush which had the same exposure.

Co-Authored-By: Claude Opus 4.6 <[email protected]>

* only guard add_item

---------

Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com>
Co-authored-by: neel <[email protected]>
Co-authored-by: johdax <[email protected]>
Co-authored-by: Claude Opus 4.6 <[email protected]>