Skip to content
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

Logger debug: true does nothing at runtime #671

Open
tfwright opened this issue Apr 22, 2024 · 2 comments
Open

Logger debug: true does nothing at runtime #671

tfwright opened this issue Apr 22, 2024 · 2 comments

Comments

@tfwright
Copy link

Docs for Logger middleware say:

In order to be able to set :debug at runtime we can pass it as a option to the middleware at runtime.

So I expected to be able to toggle response logging on at off when configuring clients at runtime by configuring it like so: {Tesla.Middleware.Logger, debug: true}

But this does not appear to change logger behavior.

Since the docs also say something about the value of Logger level at compile time, I suspect what I am trying to do may not be possible currently? But it seems like it should be. My use case is that I don't normally want to log responses in prod, but sometimes I'd like to troubleshoot an issue by consoling in to that env.

@teamon
Copy link
Member

teamon commented Apr 23, 2024

Using {Tesla.Middleware.Logger, debug: true} will call Logger.debug, but it will only show if your logger level is set to :debug (You can use Logger.configure(level: :debug) in console to change it)

@teamon teamon closed this as completed Apr 23, 2024
@teamon teamon reopened this Apr 23, 2024
@tfwright
Copy link
Author

tfwright commented Apr 23, 2024

It looks like the issue was I had some incorrectly formatted headers that seemed to work for dispatching the actual request but were breaking logging: cannot truncate chardata because it contains something that is not valid chardata. When I changed the header keys from atoms to strings request logs started appearing again.

If that is indeed the issue, what do you think about prefacing that error message with something like "error rendering logs: " to make it a bit more clear that debug line is in place of where logs would have been emitted if not for the given error.

Beyond that, possible error when non-strings are passed in header data?

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

No branches or pull requests

2 participants