one-line-logger
one-line-logger copied to clipboard
fastify
Display stacktrace when logging an error
Prerequisites
- [x] I have written a descriptive issue title
- [x] I have searched existing issues to ensure the feature has not already been requested
🚀 Feature Proposal
When an error is logged, the back-trace could be displayed alongside the error. Although this would obviously break with the name of this library as it would require multiple lines to do so. (I'd argue it is a worthy exception though.)
Motivation
@fastify/one-line-logger is typically suggested for use in dev environments. In a dev environment it is very useful to be able to see the back-trace on an error, in order to debug the issue.
Example
Vanilla pino-pretty will do this currently, albeit in not so pretty a way.
| Current @fastify/one-line-logger | Vanilla pino-pretty |
|---|---|
Note: It's possible to work around this by logging err.stack instead or err, but that doesn't strike me as the right solution.
I dont know. Seems odd for a project named one-line-logger to output a log entry multi lines
Also one-line-logger is more like the log output which is generated by other http servers.
@Uzlopak: I agree it goes against the name of the project, but my argument would be that this would be a reasonable exception. As I understand it, the main use of this project is for development environments, in that case it seems likely that errors will be encountered and the stacktrace is useful in debugging them. In the case of an unexpected error, I'd think that information trumps prettiness.
You are stating now the second time that this logger is used mainly for development. I dont see anything which hints in that direction.
Furthermore it seems that the goal was to implement Common Log Format. https://en.m.wikipedia.org/wiki/Common_Log_Format https://github.com/fastify/fastify/issues/4027
So i dont think your proposal fits the purpose of this plugin.
By the way, it would be very useful to have at least the filename and line number where the error occured
@imageinsante
Yeah, that is definetily reasonable. Should also be a 15 minute implementation.
Hi @Uzlopak.
You are stating now the second time that this logger is used mainly for development. I dont see anything which hints in that direction.
I think I was getting that idea, because it logs in colour by default, and also from this article: https://blog.platformatic.dev/exploring-vue-ssr-with-fastify
The server is using @fastify/one-line-logger for human readable logs during development, but you'll want to condition that to process.stdout.isTTY so it continues to produce regular JSON logs for production.
After doing a bit of digging, it seems that this library is built on top of pino-pretty, which state in the description of their package:
This module provides a basic ndjson formatter to be used in development.
(Although they do not state a reason why it should not be used in production.)
Anyway, please accept my apologies if I was mistaken and the library is intended for production.
However, even if the library is intended for production, I would think that a stacktrace would still be useful, as otherwise one would struggle to understand how an error was generated in their production service.
With regards to the name, 'one-line-logger', it should be noted that this logger will currently happy print line-feeds in log messages. (Which is why it works to pass err.trace to get the stacktrace.) If the intention is to never print multiple lines, then I'd suggest this a bug and that line-feeds should be removed/replaced prior to printing, or even to truncate messages to only include content before the first line-feed.
Furthermore it seems that the goal was to implement Common Log Format.
After doing some digging, it seems that the original intention behind the library is explained in this issue: https://github.com/fastify/fastify/issues/4027
My reading of that is that the decision was to produce something like pino-colada rather than Common Log Format. Interestingly, it seems from the NPM page / README that pino-colada does provide a multi-line stacktrace when an error is logged.
Obviously the intention could have changed in the years since.
FWIW, if the decision was made to provide better handling of errors, I think it would simply be a case of inspecting the log object to detect whether it is an error, in a similar way to how requests are detected and given special handling here: https://github.com/fastify/one-line-logger/blob/main/lib/message-format-factory.js#L39
For now, I've just implemented my own transport in order to get the behaviour that I'm looking for. (I'll probably publish the code in the near future, if anyone is interested in the the implementation that I used.) Here's a screenshot to show the sort or output that a library like this one could have, if the decision was made to support it:
Anyway, please accept my apologies if I was mistaken and the library is intended for production.
I was not insulted or agitated. I was just wondering where your claim comes. Because such an assessment should maybe be in the README, so that people dont use it for production.
So no need to apologize. In contrary: I feel now bad, that you felt pressured to express an apology.
Anyhow, we should consider to (re-)define the scope of this plugin. Should be used for production? Do we need to document it better? What is considered valid?
@mcollina @jsumners Can you please give a statement?
@jsumners THis is not about you maintaining this project but giving an opinion.
That is part of maintaining the project: understanding its goals and making decisions on its direction.