Trim objects that are serialized by err and errWithCause
#141
Conversation
|
| (error: unknown): unknown => | ||
| trimmer({ | ||
| depth: opts.maxObjectDepth ?? 4, | ||
| })(serializer(error as Error)); |
There was a problem hiding this comment.
Is there some way we can avoid this type assertion? 🤔
| opts: FormatterOptions, | ||
| ): SerializerFn => | ||
| (error: unknown): unknown => | ||
| trimmer({ |
There was a problem hiding this comment.
Is there any value in sharing a trimmer across the serializers? (I have no clue.)
| ): SerializerFn => | ||
| (error: unknown): unknown => | ||
| trimmer({ | ||
| depth: opts.maxObjectDepth ?? 4, |
There was a problem hiding this comment.
-
Nitpick: can we set the default (4) in one spot?
-
Could some engineers be relying on the fact that they can read deeply nested error information, e.g. to review a HTTP request and response body and figure out what caused a HTTP 400? Not to say we should encourage this practice, but it may be an easy out that is available today, and I wonder if
4is still a reasonable global default in this light.On the topic of release, I'd almost err toward a major version here.
| depth: opts.maxObjectDepth ?? 4, | ||
| })(serializer(error as Error)); | ||
|
|
||
| export const createSerializers = ( |
There was a problem hiding this comment.
I like @samchungy's question of whether we should apply this to all serialisers. Would all also include user-provided ones? 🤔
Purpose
This test fails in master with the following output, which can result in some quite nasty logs... I caught this in a few logs that were logging entire html documents 🫠
Approach
Trim the returned objected from both the err and errWithCause serializers with the desired formatting options.