fix: reject unknown config keys so typos fail at startup - #682
Merged
Conversation
Most config sections silently dropped unknown keys, so a mistyped setting name was ignored and the service ran the default with no warning. Enable strict key checking on the top-level config and every section that lacked it, so a typo now fails at startup naming the bad key.
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.
This PR makes the dipper service reject a config file that contains an unknown key, so a mistyped setting name fails at startup with an error naming the bad key instead of being silently ignored. The service reads its settings from a JSON config, and most sections previously accepted any extra key and dropped it, which meant a typo like
intervlforintervalleft that section running its default with no sign the setting never took effect. Before this, only 3 of the 18 config structs rejected unknown keys; this turns on the same strict checking for the top-level config and every remaining section, including the kafka block used for event streaming.One rollout note: a deployed config that carries a stray or renamed key will now fail to start rather than boot with it ignored. The example config in
k8s/configmap-example.yamlonly uses real keys, so it is unaffected, but check any live config for leftover keys before deploying.