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

New 'fatal' log level for critical unrecoverable application errors (as opposed to standard user 'error' level) #11945

Closed
1 task done
Frank-D opened this issue Jun 29, 2023 · 3 comments
Labels
effort1: hours priority: low (4) Low-priority issue that needs to be resolved type: enhancement 🐺

Comments

@Frank-D
Copy link

Frank-D commented Jun 29, 2023

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

I find it not super convenient having to combine both critical application errors (e.g. application code bug, or application logic bug) AND user interaction errors (e.g. user trying to do something not supported by the application, or perhaps bad user inputs even though those could be mapped to less critical log levels such as verbose, debug, info or warn..).

Describe the solution you'd like

A new 'fatal' (or 'critical') log level introduced and leveraged in the default ootb nestjs logger classes (Logger, ConsoleLogger, LoggerService, etc), which would now allow to easily differentiate/isolate application 'fatal' from 'error' problems.

Teachability, documentation, adoption, migration strategy

Very simple doc update to introduce a new method signature in the LoggerService code snippet listed here.

No migration strategy needed, since this remains backward compatible, e.g. no breaking change introduced. Users can simply start leveraging the new 'fatal/critical' log level, if they want/need to. All their existing code relying on all other existing and kept log levels will still work.

What is the motivation / use case for changing the behavior?

In the end, if ALL application errors end up being identified all the same, e.g. under ERROR log level, then it makes it hard for us apps developers to quickly identify which of all these potential errors are actual critical unrecoverable application errors that require our immediate attention and will require actual application code or configuration fix or else they'll continue to generate errors to users trying the same functionality.

@Frank-D Frank-D added needs triage This issue has not been looked into type: enhancement 🐺 labels Jun 29, 2023
@kamilmysliwiec
Copy link
Member

Would you like to create a PR for this issue?

@Mexidense
Copy link

Hey, folks 👋🏽

Apache Log4j uses this standard and as @Frank-D said, the Fatal level error is used to prevent the application from continuing and allow to easily differentiate/isolate application 'fatal' from 'error' problems.

Could we add this fatal level error? I have never contributed to NestJS and I would like to, can I?

@micalevisk micalevisk removed the needs triage This issue has not been looked into label Jul 4, 2023
@kamilmysliwiec kamilmysliwiec added effort1: hours priority: low (4) Low-priority issue that needs to be resolved labels Jul 18, 2023
TheCodby added a commit to TheCodby/nest that referenced this issue Jul 29, 2023
TheCodby added a commit to TheCodby/nest that referenced this issue Jul 29, 2023
@kamilmysliwiec
Copy link
Member

Let's track this here #12161

kamilmysliwiec added a commit that referenced this issue Aug 18, 2023
feat(common): added "fatal" as a log level (issue #11945)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort1: hours priority: low (4) Low-priority issue that needs to be resolved type: enhancement 🐺
Projects
None yet
Development

No branches or pull requests

4 participants