fix(sink-pino): thread wrapper level into pino so debug records actually emit#25
Merged
Conversation
…lly emit Closes #24 Without this, createLogger({ level: "debug" }) silently dropped debug records on the default Node pino stream because the underlying pino instance was constructed with no level and defaulted to info. The wrapper-level filter let debug calls through, but pino threw them away at the sink. GCP and edge sinks were unaffected. Also export parseLevel and map pino aliases (trace -> debug, fatal -> error) so consumers can validate process.env.LOG_LEVEL without an unsafe cast and without producing total silence on unknown values.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Fix
createLogger({ level: "debug" })so debug records actually reach the default pino stream. ExportparseLeveland accept pino aliases (trace,fatal) so callers porting from pino do not get silence on unknownLOG_LEVELvalues.Why
Caught by @nascode while reviewing tetratelabs/fraser-auth#170. The pino sink was building its pino instance from
opts?.pino ?? {}only, soopts.levelnever reached pino. Pino defaulted toinfo, the wrapper allowed debug calls through, and pino dropped them at the sink. Dev and tests lost debug output. Prod was fine because the GCP sink writes viaconsole.logand never went through pino's level filter.The secondary
LOG_LEVEL=tracesilence is a footgun in the same vein: an unsafeas Levelcast lets unrecognised strings through, thenshouldLogevaluatesundefined >= Nas false for every level, includingerror.How
sink-pino.tsthreadsopts.levelinto pino whenpino.levelis not already set. Explicitpino.levelstill wins.SinkOptionsgrows an optionallevelfield so the sink can read it.parseLevelis exported from both node and edge entry points. It mapstracetodebugandfataltoerror; other unknown values fall back toinfo.Verification
pnpm typecheckpnpm buildpnpm test— 90 / 90 passing, 7 new tests intest/sink-pino.test.tscover the regression and the pino aliases.pnpm format:checkdebug-visibleandinfo-visible.Notes
Consumer side (fraser-auth#170) lands in a follow-up that bumps to 0.3.2 and swaps the inline
as Levelcast forparseLevel.