`void/log` serializes `Error` fields as `{}`, losing message and stack
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
Issue này chưa được đánh giá.
Mô tả
Summary
logger.error() is meant for surfacing caught errors (#168), but an Error passed as a field is logged as {}. Its message, stack and cause are non-enumerable, so JSON.stringify drops them. Nothing fails, so this goes unnoticed until someone needs the log.
Reproduction
[email protected] (same code on main):
import { logger } from 'void/log';
logger.error('save failed', { error: new Error('boom') });
// {"msg":"save failed","error":{}}
logger.error('save failed', { error: new Error('wrapped', { cause: new Error('inner') }) });
// {"msg":"save failed","error":{}}
class AppError extends Error {
status = 500;
}
logger.error('save failed', { error: new AppError('boom') });
// {"msg":"save failed","error":{"status":500}}
Expected
The error's details are kept, for example:
{"msg":"save failed","error":{"name":"Error","message":"boom","stack":"Error: boom\n at ..."}}
Suggested fix
Pass a replacer to the existing JSON.stringify call in format(). This also covers nested errors and cause chains, keeps custom enumerable fields such as status, and leaves the { msg, ...fields } shape unchanged:
function replacer(_key: string, value: unknown) {
if (value instanceof Error) {
return { ...value, name: value.name, message: value.message, stack: value.stack, cause: value.cause };
}
return value;
}
return JSON.stringify(payload, replacer);
The existing catch fallback still handles circular references.
If passing Error objects is intentionally unsupported, a note in the logger docs to pass error.message / error.stack as strings would help.
- Ngôn ngữ chính
- TypeScript
- Star
- 580
- Fork
- 56
- Merge trung bình
- 8 giờ 32 phút
- Pull request đã merge (30 ngày)
- 111
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
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của voidzero-dev/void
-
Dev: `better-auth/client/plugins` fails to resolve when auth is enabled (the `better-auth/client` alias matches it as a prefix)Có thể đã có người làm @MaxtuneLee đã nhận 1 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
voidzero-dev/void#565 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
prepareDeployArtifact omits worker.vars that the CLI managed deploy includesCó thể đã có người làm @dvkam đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
voidzero-dev/void#529 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 78/100
voidzero-dev/void#428 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
voidzero-dev/void#579 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
vp build / void deploy exit 0 when a page fails to prerender, and the page is silently missingĐang mở
voidzero-dev/void#576 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của voidzero-dev/void
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
awesome-dsh-plugin/awesome-dsh-plugin#9184 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
farion1231/cc-switch#8829 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[core-client] Remove unused hand-maintained transport helpers after the definition-table cutoverĐang mởdoc-audit enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100