Skip to content

feat(mapper): reject configs with unknown fields#687

Open
SAY-5 wants to merge 1 commit intoprometheus:masterfrom
SAY-5:feat/strict-yaml-unknown-fields-546
Open

feat(mapper): reject configs with unknown fields#687
SAY-5 wants to merge 1 commit intoprometheus:masterfrom
SAY-5:feat/strict-yaml-unknown-fields-546

Conversation

@SAY-5
Copy link
Copy Markdown

@SAY-5 SAY-5 commented Apr 22, 2026

Closes #546.

Change

`MetricMapper.InitFromYAMLString` now parses the mapping config with `yaml.UnmarshalStrict` (already provided by `go.yaml.in/yaml/v2`). Any key that the target struct tags don't expose — a misspelled `nmae:` in place of `name:`, a stale field from an older version, etc. — now fails to load with an error that names the unknown field, rather than being silently dropped.

This is exactly the failure mode the issue calls out (and the one that produced the confusion in #544 before it): the old permissive behavior made misconfigurations impossible to notice until the downstream mapping just didn't fire.

Breaking change disclaimer

As the issue notes, this is "potentially-breaking in the sense that your configuration no longer silently does something you didn't expect". Any config file that was relying on unknown keys being ignored will start returning an error on reload. That's intentional — the whole point is to surface those. Release notes should highlight it, and my PR description here is the natural anchor for that note.

Tests

Added `TestStrictConfigUnknownField` in `pkg/mapper/mapper_test.go` that feeds a mapping entry with a misspelled `nmae:` key and asserts that `InitFromYAMLString` returns an error mentioning the unknown field:

```
$ go test -count=1 -run TestStrictConfigUnknownField -v ./pkg/mapper/...
=== RUN TestStrictConfigUnknownField
--- PASS: TestStrictConfigUnknownField (0.00s)
PASS
```

Full suite (`go test -count=1 ./...`) passes.

Signed-off-by: SAY-5 SAY-5@users.noreply.github.com

InitFromYAMLString now decodes the mapping file with
yaml.UnmarshalStrict, so keys the MetricMapper struct doesn't expose
(e.g. a misspelled `nmae:` instead of `name:`) return an error instead
of being silently dropped -- the failure mode called out in prometheus#546 and
issue prometheus#544 before it.

This is a user-facing breaking change in the narrow sense: configs
that were silently doing nothing now fail loudly. Release notes should
call it out.

Adds TestStrictConfigUnknownField that exercises the rejection path
on a mapping entry with a misspelled `nmae:` key.

Closes prometheus#546.

Signed-off-by: SAY-5 <SAY-5@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Reject configuration with unknown fields

1 participant