Telemetry attach warnings: Function passed as a handler with ID

i-n-g-m-a-r

Running mix test on a new Phoenix installation (1.5.9) results in many “Function passed as a handler with ID’” messages.

Does anyone know whether this is a problem and how to solve it?

Thank you.

09:13:48.858 [info]  Function passed as a handler with ID {Phoenix.Logger, [:phoenix, :channel_handled_in]} is local function.
This mean that it is either anonymous function or capture of function without module specified. That may cause performance penalty when calling such handler. For more details see note in `telemetry:attach/4` documentation.

https://hexdocs.pm/telemetry/telemetry.html#attach-4

09:13:48.871 [info]  Function passed as a handler with ID {Phoenix.Logger, [:phoenix, :channel_joined]} is local function.
This mean that it is either anonymous function or capture of function without module specified. That may cause performance penalty when calling such handler. For more details see note in `telemetry:attach/4` documentation.

https://hexdocs.pm/telemetry/telemetry.html#attach-4

09:13:48.871 [info]  Function passed as a handler with ID {Phoenix.Logger, [:phoenix, :endpoint, :start]} is local function.
This mean that it is either anonymous function or capture of function without module specified. That may cause performance penalty when calling such handler. For more details see note in `telemetry:attach/4` documentation.

https://hexdocs.pm/telemetry/telemetry.html#attach-4

09:13:48.871 [info]  Function passed as a handler with ID {Phoenix.Logger, [:phoenix, :endpoint, :stop]} is local function.
This mean that it is either anonymous function or capture of function without module specified. That may cause performance penalty when calling such handler. For more details see note in `telemetry:attach/4` documentation.

https://hexdocs.pm/telemetry/telemetry.html#attach-4

09:13:48.872 [info]  Function passed as a handler with ID {Phoenix.Logger, [:phoenix, :error_rendered]} is local function.
This mean that it is either anonymous function or capture of function without module specified. That may cause performance penalty when calling such handler. For more details see note in `telemetry:attach/4` documentation.

https://hexdocs.pm/telemetry/telemetry.html#attach-4

09:13:48.872 [info]  Function passed as a handler with ID {Phoenix.Logger, [:phoenix, :router_dispatch, :start]} is local function.
This mean that it is either anonymous function or capture of function without module specified. That may cause performance penalty when calling such handler. For more details see note in `telemetry:attach/4` documentation.

https://hexdocs.pm/telemetry/telemetry.html#attach-4

09:13:48.872 [info]  Function passed as a handler with ID {Phoenix.Logger, [:phoenix, :socket_connected]} is local function.
This mean that it is either anonymous function or capture of function without module specified. That may cause performance penalty when calling such handler. For more details see note in `telemetry:attach/4` documentation.

https://hexdocs.pm/telemetry/telemetry.html#attach-4

7 comments

/phoenix #telemetry

1 2001 7

2022-02-25 10:00:39 UTC

First 7 of 7 Posts

03juan

I just tried it on a fresh 1.5.9 install and don’t see those errors. Did you make any changes to the dependencies?

Out the box phx_new 1.5.9 depends on telemetry_poller v0.4 which would install v0.5.1, but the link in the errors suggests you’re using 1.0, which depends on telemetry 1.0, so you may have a version mismatch.

Post #1

hauleth

Update Phoenix.

Yes, I know whether it is problem - I have implemented that warning.

It can be problem in production as calling local captures between processes (and storing them in ETS) can be quite expensive due to BEAM guarantees about local calls. Remote captures (aka one in form of &module.function/arity) are much less expensive, as these are almost equivalent to just 3-ary tuple ({module, function, arity}). Phoenix used local captures there in the past, and now it is fixed.

Post #2

03juan

If they want to use 1.5.9 to follow a book or tutorials, would it be easy to change where those calls are made? Or at least they can live with the warnings. Unless the intention is a production system, in which case definitely upgrade.

Post #3

i-n-g-m-a-r

Below is the output for mix deps.update --all
My mix.exs file defines {:phoenix, "~> 1.5.9"}
The actual phoenix version seems to be phoenix 1.5.13
The messages remain the same.

  connection 1.1.0
  cowboy 2.9.0
  cowboy_telemetry 0.4.0
  cowlib 2.11.0
  db_connection 2.4.1
  decimal 2.0.0
  ecto 3.7.1
  ecto_sql 3.7.2
  elixir_uuid 1.2.1
  file_system 0.2.10
  gettext 0.19.1
  jason 1.3.0
  mime 2.0.2
  oban 2.11.1
  phoenix 1.5.13
  phoenix_ecto 4.4.0
  phoenix_html 2.14.3
  phoenix_live_dashboard 0.6.5
  phoenix_live_reload 1.3.3
  phoenix_live_view 0.17.7
  phoenix_pubsub 2.0.0
  plug 1.13.3
  plug_cowboy 2.5.2
  plug_crypto 1.2.2
  postgrex 0.16.2
  ranch 1.8.0
  telemetry 1.0.0
  telemetry_metrics 0.6.1
  telemetry_poller 1.0.0

Post #4

03juan

Yes if the project was initialised with phoenix 1.5.x and now you’ve upgraded telemetry to 1.0 and live_view to 0.17 then why not upgrade to phoenix 1.6 as per @hauleth?

Post #5