getsentry / sentry-elixir

The official Elixir SDK for Sentry (sentry.io)
https://sentry.io
MIT License
613 stars 181 forks source link

Unexpected message arrived into Sentry.Transport.Sender when using Finch #732

Open ruslandoga opened 2 months ago

ruslandoga commented 2 months ago

👋

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.

whatyouhide commented 1 month ago

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?