Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Error logging is called even when handled in custom handler.

Đang mở
  • Có gì không ổn?
#208 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
javascript, nodejs
Lĩnh vực
api, backend

Hướng nghiên cứu

Issue không nêu tên file hoặc test nào. Hãy lần theo các entry point của custom error-handler và default error-handler, sau đó xác minh rằng các lỗi đã được xử lý không phát ra default error log, trong khi các lỗi được chuyển tiếp vẫn phát ra log đó, và access log vẫn giữ mã trạng thái cuối cùng.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
JavaScript
Star
1.5k
Fork
127
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của jeremydaly/lambda-api

Tất cả issue của jeremydaly/lambda-api

Issue tương tự

Thêm issue về JavaScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.