Skip to content

Fix regression in Logger :metadata config #13546

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

drewble
Copy link

@drewble drewble commented May 8, 2024

When upgrading Elixir from 1.14 to 1.16 in our Phoenix app the project fails to start when Logger exits due to an argument error in the Enum.into/2 call in logger/app.ex when reading in the values from config.

Screenshot 2024-05-08 at 9 27 18 AM

The Logger documentation describes the metadata property of the config as a list of atoms.

config :logger, :default_formatter,
  format: "[$level] $message $metadata\n",
  metadata: [:error_code, :file]

Enum.into/2 on logger/app.ex:40 fails when reading this structure in as it expects a keyword list it can convert to map.

Looking at logger_test.exs from the PR where the Enum.into/2 call was added shows that the test is setting the metadata config as a keyword list

Application.put_env(:logger, :metadata, global_meta: :yes)

This patch uses Enum.into/3 to handle both cases with a transform, defaulting to :yes as the value when receiving a list of atoms as described throughout the Logger docs.

@josevalim
Copy link
Member

I beleive there is some confusion here. Those are two keys named metadata, but with different behaviour. The root metadata is indeed key-value pairs that is added to the metadata. The metadata in default formatter are the metadata keys you want to include in the formatted messages.

The reason why your app is failing is because you were configuring the metadata in the wrong place and it had no effect. And new Eixir assigned a meaning to it. You should move the metadata you had either to a backend or to the formatter, but not at the root. :)

@josevalim josevalim closed this in 69999ec May 8, 2024
@drewble
Copy link
Author

drewble commented May 9, 2024

Thanks for the review! With your feedback in mind, I went back to the docs and found my answer in the Backends and backwards compatibility section.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants