Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Error logging is called even when handled in custom handler.

Aperta
  • Qualcosa non va?
#208 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
javascript, nodejs
Ambito
api, backend

Direzione di ricerca

Nell’issue non sono indicati file o test. Traccia i punti di ingresso dell’handler degli errori personalizzato e dell’handler degli errori predefinito, quindi verifica che gli errori gestiti non producano il log degli errori predefinito, mentre gli errori inoltrati continuino a produrlo, e che il log di accesso mantenga il codice di stato finale.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
JavaScript
Stelle
1.5k
Fork
127
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di jeremydaly/lambda-api

Tutte le issue di jeremydaly/lambda-api

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.