feat!: worker friendly logger instances - #5490
Merged
Merged
Conversation
Contributor
Performance Report鉁旓笍 no performance regression detected Full benchmark results
|
dapplion
changed the title
Comment on lines
+16
to
+29
| "exports": { | ||
| ".": { | ||
| "import": "./lib/index.js" | ||
| }, | ||
| "./browser": { | ||
| "import": "./lib/loggers/browser.js" | ||
| }, | ||
| "./node": { | ||
| "import": "./lib/loggers/node.js" | ||
| }, | ||
| "./empty": { | ||
| "import": "./lib/loggers/empty.js" | ||
| } | ||
| }, |
Contributor
There was a problem hiding this comment.
Instead of subpath exports why not not use conditional exports https://nodejs.org/api/packages.html#conditional-exports. And only default export. This way user can use a consistent import pattern.
"exports": {
".": {
"node": "./lib/loggers/node.js",
"browser": "./lib/loggers/browser.js",
"default": "./lib/index.js"
},
},
wemeetagain
approved these changes
May 15, 2023
nflaig
reviewed
May 29, 2023
| // Return a new logger instance with different module and log level | ||
| // but a reference to the same transports, such that there's only one | ||
| // transport instance per tree of child loggers | ||
| child(opts: LoggerNodeChildOpts): LoggerNode { |
Member
There was a problem hiding this comment.
@dapplion This changed how we create child loggers, it creates a new event listener for each child logger
Was the previous implementation not compatible when using workers?
Using native winston.child does not work as mention in previous comment.
Workaround for now is to just increase max listeners which should be fine to do as explained in the PR
Contributor
Author
There was a problem hiding this comment.
Hmm unsure of the reason forgot to document, so may be an oversight. Could you test if the previous approach works fine still?
Member
There was a problem hiding this comment.
Child loggers are only created in the main thread, does not affect workers at all because we initialize a completely new logger instance there
Opened a PR to revert logger.child implementation back to original approach
nflaig
reviewed
May 29, 2023
| const filename = opts.file.filepath; | ||
|
|
||
| transports.push( | ||
| opts.file.dailyRotate != null |
Member
There was a problem hiding this comment.
What's the expected approach to disable log file rotation now?
The comment above does not longer match behavior as setting --logFileDailyRotate 0 will still initialize DailyRotateFile. Default winston.transports.File is effectively never used now.
Contributor
Author
There was a problem hiding this comment.
Right, logFileDailyRotate is a bit a weird UX flag. Does yargs support accepting both syntax with no arg --logFileDailyRotate and with arg --logFileDailyRotate 5? That would make handling easier
Member
There was a problem hiding this comment.
Both works, but setting --logFileDailyRotate (without value) and omitting the flag will result in 5 due to the fact that we set it as default here
Setting it to 0 to disable daily file rotation seems logical to me (and is most explicit), that's also how it worked previously
Member
|
馃帀 This PR is included in v1.9.0 馃帀 |
1 task
nazarhussain
added a commit
that referenced
this pull request
Aug 7, 2026
- unskip is_one_confirmed_fails_large_validator_slashed: passes on the slot-start schedule since consensus-specs #5490 reordered the slashing before the tick - assert safe_execution_block_hash (consensus-specs #5449) and the FastConfirmationStore variables in every FCR checks step, exposed via IForkChoice.getFastConfirmationStore() - return ZERO_HASH from getSafeExecutionBlockHash for a genesis anchor: the genesis block body carries a default payload so it is not an execution block per spec; proto array reports the state header hash - skip vectors blocked on upstream generation artifacts (stub deposit signatures, double/skipped on_fast_confirmation runs) and the gloas suite pending the alpha.13 gloas implementation Refs #9690 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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
4 participants
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.
Motivation
Our current Logger instances are not DX friendly to support workers.
Let's list the requirements:
@lodestar/light-clientor@lodestar/reqrespjust want access to a generic simple Logger instance to write data at some LogLevel. No need to expose them to more complicated loggers or to force dependencies on NodeJS specific code@lodestar/beacon-nodeneed access to a generic logger with more features, specifically:2.1. Create child logger with custom settings, which must re-use references to the same transport instances
2.2. Serialize a logger instance settings and transport settings for a worker downstream
@lodestar/clihas to be able to produce compatible logger instances for the above casesDescription
So to fulfill 1. and 2. there must exist separate insterfaces, which are:
LoggerLoggerNodeLoggerNodecan export its settings withtoOpts()and be recreate with those