fix(config): fail loudly on invalid or fractional numeric config#24536
Merged
PhilWindle merged 4 commits intoJul 6, 2026
Merged
Conversation
numberConfigHelper and optionalNumberConfigHelper used parseInt, which
silently truncated decimals (parseInt('0.8') === 0). A user setting an
integer config to a fractional value ended up with an unexpected value
and no warning. Both helpers now parse with parseFloat and throw when the
result is not a safe integer, so misconfiguration fails loudly. Values
that legitimately need decimals already have floatConfigHelper and
percentageConfigHelper.
Fixes A-1398
An audit of numberConfigHelper call sites surfaced options whose default is already fractional but were parsed as integers: - p2p gossipsub tx scoring params (topic weight, invalid-message-delivery weight and decay) feed libp2p's float TopicScoreParams; the decay defaults to 0.5. - The sequencer per-block DA allocation multiplier defaults to 1.5 and its sibling perBlockAllocationMultiplier already uses floatConfigHelper. With number config helpers now rejecting non-integers, an operator setting any of these to a decimal would fail at startup, so migrate them to floatConfigHelper.
Continue the numberConfigHelper audit: these options accept a percentage or multiplier where a fractional value is meaningful, so parse them as floats rather than rejecting decimals. - L1 tx fee percentages: gasLimitBufferPercentage, priorityFeeBumpPercentage and priorityFeeRetryBumpPercentage (e.g. a 12.5% buffer). - bot minFeePadding, consumed as the fractional overpay factor 1 + padding (the wallet-sdk defaults the same concept to 0.5); its zod schema no longer pins it to an integer.
…g default numberConfigHelper, floatConfigHelper and percentageConfigHelper swallowed unparseable input and returned the config default, so a typo'd or malformed value ran silently with an unexpected value. The default is meant for an unset env var only (empty/unset is already resolved to the default before parseEnv runs), so parseEnv now throws on any set-but-invalid value. Updated the misleading '...or is invalid' JSDoc accordingly.
spalladino
changed the title
PhilWindle
approved these changes
Jul 6, 2026
PhilWindle
deleted the
spl/a-1398-number-config-options-silently-truncate-decimals
branch
July 6, 2026 16:32
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.
Human-written summary
Invalid numeric values in config were silently ignored and replaced with the default. Also, config entries defined with
numberConfigHelperaccepted non-integer values but silently truncated them.Context
The numeric config helpers mishandled bad input in two ways:
numberConfigHelper/optionalNumberConfigHelperparsed withparseInt, which silently truncated decimals — an integer config set to0.8became0with no warning. In the worst case (A-1312) that turned a fractional retention window into0, i.e. "delete immediately".numberConfigHelper,floatConfigHelperandpercentageConfigHelperswallowed any unparseable value and returned the config default (the JSDoc even documented "...or is invalid"), so a typo'd env var ran silently with an unexpected value.Approach
The config default is for an unset env var only — empty/unset is already resolved to the default before
parseEnvruns, so the only thingparseEnvreturning a default achieved was hiding bad input. The helpers now parse strictly and throw on any set-but-invalid value:numberConfigHelper/optionalNumberConfigHelper: parse withparseFloatand require a safe integer (no more silent truncation).floatConfigHelper/percentageConfigHelper: require a finite number; percentage additionally enforces 0–1.bigint,enumand the secret helpers already threw on invalid input.booleanConfigHelperis intentionally unchanged:parseBooleanEnvis a total function (unrecognized tokens map tofalse), it never substitutes the configured default.Auditing all ~150
numberConfigHelpercall sites then surfaced options that legitimately take fractional values and would now wrongly reject them; these were moved tofloatConfigHelper:0.5), which feed libp2p's floatTopicScoreParams.perBlockDAAllocationMultiplier(default1.5); its siblingperBlockAllocationMultiplieralready usedfloatConfigHelper.gasLimitBufferPercentage,priorityFeeBumpPercentage,priorityFeeRetryBumpPercentage.minFeePadding, consumed as the fractional overpay factor1 + padding; its zod schema no longer pins it to an integer.Impact
A node whose numeric config env var (or CLI flag) is set to a non-numeric, fractional (for integer options), or out-of-range value now fails at startup with a clear error instead of silently running with a truncated or default value. Operators relying on the old lenient behavior must correct the value.
Fixes A-1398