Just to answer this question directly: Sentry should not leak this message. They are probably using Task.async while they should be using something like Task.Supervisor.start_child. If they are leaking it on purpose, then you need to handle it. Adding a clause like handle_info({ref, _}, state) when is_reference(ref), do: {:noreply, state} is enough.
2 Likes
Hey, I stumbled upon the same problem recently and I am very grateful for your post here! I hadn’t thought that these identifiers were for Sentry events!
You probably have this under control already and Jose’s answer is one of the solutions to the problem, but after a bit of research I found that there as an issue in the sentry-elixir repo and a (pull request](https://github.com/getsentry/sentry-elixir/pull/174) that was merged after that regarding this. I believe that if you add result: :sync (if you do want to use the event_id for something) or result: :none as a second argument (opts) to Sentry.capture_exception/3 should also fix this issue.
Some more helpful links that my inquiry followed:
https://hexdocs.pm/sentry/Sentry.html#module-capturing-exceptions
https://hexdocs.pm/sentry/Sentry.Client.html#send_event/2 - the documentation for the :result option
https://hexdocs.pm/elixir/Task.Supervisor.html#async_nolink/3-compatibility-with-otp-behaviours
Just in case you or someone else stumbles upon this issue. 
1 Like
