Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Error logging is called even when handled in custom handler.

Abierto
  • ¿Algo no está bien?
#208 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
javascript, nodejs
Área
api, backend

Línea de trabajo

En el issue no se menciona ningún archivo ni prueba. Rastrea los puntos de entrada del controlador de errores personalizado y del controlador de errores predeterminado; después, verifica que los errores gestionados no emitan el registro de errores predeterminado, mientras que los errores reenviados sigan haciéndolo, y que el registro de acceso conserve el código de estado final.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

When the error logging is enabled, it is called even when the error is handled in a custom error handler middleware.

This is unintuitive for several reasons. Consider the following case.

//Validation middleware
api.use((req, _, next) => {
    //Assume a function that validates the body and returns a boolean
    if (!validate(req.body)) {
        throw new CustomValidationError();
    }

    next();
});

/*Some routes registered here*/

//Error handling middleware
api.use((err, _, res, next) => {
    //Handle validation errors and send the response
    if (err.name === 'CustomValidationError') {
        return res.status(422).json({reason: 'Some validation reason'});
    }

    next();
});

In this case, the first thing we see in the logs is something like INFO {"level":"fatal",..."statusCode":500}.

Clearly the error is not something that we would consider to be fatal, as we handle it and return a 4XX. Also, the status code says 500, because that's the default in the handling logic and we haven't overridden it at the point at which the log is written, but it's confusing to see these things for a request which is neither fatal nor a 500.

The access log will then be printed with the correct status code, which adds further confusion.

Finally, the readme states that we can "short-circuit" the default error handler by registering a custom one, which I would expect to mean that we only get the logging if we don't register a custom handler, or we call next(), because it seems intuitive that the logging is part of the default handler.

Thank you for taking time to read.

Lenguaje dominante
JavaScript
Estrellas
1.5k
Forks
127
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de jeremydaly/lambda-api

Todos los issues de jeremydaly/lambda-api

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.