Telemetry attach warnings: Function passed as a handler with ID

Questions / Help
,
1

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
1 Like
2

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.

1 Like
3

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.

5 Likes
4

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.

1 Like
5

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
6

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?

2 Likes
7

Thank you both, that works.

It didn’t occur to me that mix phx.new would not install the latest version.
I should pay better attention.

8

You need to upgrade the phx_new package from hex every time a new Phoenix version is released.

 mix archive.install hex phx_new latest

Or at least before you start a new project.

2 Likes