sentry-elixir Unexpected message arrived into Sentry.Transport.Sender when using Finch

👋

Environment

Sentry client version is 10.2.0, here's how it's configured:

Steps to Reproduce

I don't have steps to reproduce right now, but here's what happened:

Sentry.Transport.Sender #PID<0.4049.0> received unexpected message in handle_info/2: {#Reference<0.3816707680.1885601808.209705>,
 {:reuse,
  %{
    parent: #PID<0.4999.0>,
    port: 443,
    scheme: :https,
    opts: [
      transport_opts: [keepalive: true, nodelay: true, timeout: 5000],
      ssl_key_log_file_device: nil
    ],
    host: "sentry.plausible.io",
    mint: %Mint.HTTP1{
      host: "sentry.plausible.io",
      port: 443,
      request: nil,
      streaming_request: nil,
      socket: {:sslsocket,
       {:gen_tcp, #Port<0.192176>, :tls_connection, :undefined},
       [#PID<0.11233156.0>, #PID<0.11233455.0>]},
      transport: Mint.Core.Transport.SSL,
      mode: :passive,
      scheme_as_string: "https",
      requests: {[], []},
      state: :open,
      buffer: "",
      proxy_headers: [],
      private: %{},
      log: false
    },
    last_checkin: -576451237288366744,
    max_idle_time: :infinity
  }, 924031935}}

The message looks similar to https://github.com/sneako/finch/blob/71f469c46d3d8ea9993d986789cef8d14bcc819c/lib/finch/http1/pool.ex#L201, but why did it arrive in Sentry.Transport.Sender is unclear: Sentry.Transport.Sender is supposed to be used only with logger handlers, and we use a custom logger backend still.

Expected Result

The goal of opening this issue is to find out what sent the message and why it was sent to Sentry.Transport.Sender.

May 15 '24 12:05 ruslandoga

Interesting, yeah this is not supposed to happen. The Logger backend and handler use the same code to send exceptions (passing result: :none to Sentry.capture_exception/2, so both use the sender thing).

I wouldn't exclude that this might be an issue with Finch leaking messages, or nimble_pool (the pooling library that Finch uses) leaking messages. Should we try to open an issue in those too?

May 31 '24 16:05 whatyouhide

👋

This error doesn't appear in our recent logs anymore, so maybe it has been "fixed" in the dependencies :)

Dec 04 '24 12:12 ruslandoga

I think this might have happened because Sentry.Transport was try/catch-ing exits and there was a race condition between NimblePool's internal deadline and the receive timeout in the caller and the checkout reply was sent to a "timed-out" caller that wasn't dead -- because the exit was caught.

Sep 28 '25 21:09 ruslandoga