fix: standardise LOG_LEVEL across all execution-client entrypoints#1006
Open
fix: standardise LOG_LEVEL across all execution-client entrypoints#1006
Conversation
All three execution-client entrypoints handled log verbosity differently, making it hard to set consistent log levels across client types via a single environment variable. Problems fixed: 1. reth-entrypoint: an unrecognised LOG_LEVEL silently fell through to the default (info/vvv) with only an echo warning. Operators mistyping 'INFO' or 'WARNING' would get no indication the value was ignored. Changed the wildcard arm to print to stderr and exit 1. 2. geth-entrypoint: only GETH_VERBOSITY (numeric, 0-5) was supported. Added LOG_LEVEL pre-processing that maps error/warn/info/debug/trace to the corresponding numeric verbosity. GETH_VERBOSITY is used as fallback when LOG_LEVEL is not set, preserving backwards compatibility. 3. nethermind-entrypoint: same issue as geth. Added LOG_LEVEL mapping block translating to Nethermind's Error/Warn/Info/Debug/Trace strings. After this change operators can set LOG_LEVEL=debug once in their .env file and have it apply uniformly across all three clients, matching the behaviour that already exists for OP_NODE_LOG_LEVEL on the consensus side. All existing GETH_VERBOSITY / NETHERMIND_LOG_LEVEL variables continue to work unchanged.
Collaborator
🟡 Heimdall Review Status
|
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
2 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.
Problem
All three execution-client entrypoints (
reth,geth,nethermind) handle log verbosity differently, making it impossible to set a consistent log level across client types with a single environment variable.Specific issues:
reth-entrypoint: an unrecognised
LOG_LEVELvalue silently fell through to the default (info) with only anechowarning — no stderr, no exit code. Operators mistypingINFOorWARNINGgot no feedback.geth-entrypoint: only
GETH_VERBOSITY(numeric,0–5) was supported. There was no human-readable alternative.nethermind-entrypoint: only Nethermind-specific capitalised level names (
Info,Debug, etc.) were accepted viaNETHERMIND_LOG_LEVEL. No shared interface with the other clients.Meanwhile the consensus side already supports
OP_NODE_LOG_LEVEL=info— there was no equivalent for execution clients.Solution
casearm to print an error to stderr andexit 1LOG_LEVELpre-processing block that mapserror/warn/info/debug/trace→ numeric verbosity; falls back toGETH_VERBOSITYwhenLOG_LEVELis unsetError/Warn/Info/Debug/Tracestrings; falls back toNETHERMIND_LOG_LEVELResult
Operators can now set
LOG_LEVEL=debugonce in their.envfile and have it apply uniformly across all three execution clients.Backwards compatibility
All existing
GETH_VERBOSITYandNETHERMIND_LOG_LEVELvariables continue to work unchanged.LOG_LEVELonly takes effect when explicitly set.