Closed alexmuller closed 4 months ago
The issue with renaming the field is that we'd need some logic that'll be annoying to maintain. What if that field is already set? Do we then have to warn that it's been overwritten or do we not set the timestamp if that's the case? I think it's worth investigating whether there's a way we can stop Pino overwriting this property (if that's what's happening)
This is a smaller issue than I originally thought. The timestamp is only stripped when using pino-pretty, because it has to make a decision about whether to use the time
or timestamp
property when rendering the date.
The test in this PR illustrates that, in production, the timestamp is still present. Do we still want to do anything about this? It's a little confusing but possibly enough of an edge-case to ignore (anyone having the same issue in future will hopefully find this issue).
@apaleslimghost, @alexmuller, thoughts?
hahahaha okay wow. yeah let's close this
Reported by Kara in #cp-reliability.
Node.js version: v20.10.0 Impacted package(s): logger@3.1.1 (latest)
Steps to reproduce
Expected behaviour
Dunno, maybe a warning that whatever you put in the timestamp property is gone forever?
Or (suggestion from Kara) we also rename that field to something else to keep it.