Raise ValidationError from the config test validators - #1456
Merged
Conversation
`frequenz-quantities` 1.0.2 changed its `marshmallow` optional dependency floor from `< 4` to `>= 4` (frequenz-floss/frequenz-quantities-python#107), correcting metadata that had been wrong since that library was ported to `marshmallow` 4. That cap was the only thing holding us on `marshmallow` 3, as our own requirement has allowed `< 5` since 870e880, so CI now resolves `marshmallow` 4. `marshmallow` 4 removed support for validators that signal failure by returning `False`, deprecated in 3.24.0: Custom validators must raise a `ValidationError` for invalid values (deprecated in 3.24.0). Returning `False` is no longer supported. The configuration test dataclasses used exactly that pattern, a `lambda s: s.startswith("test")` in the field metadata. The validator is still registered and still called, only its return value is ignored, so the invalid value is accepted and `test_load_config_dataclass` and `test_new_receiver_configurations[Validation Error]` fail. Replacing the lambdas with a function that raises restores the checks. The message stays `Invalid value.`, which is what `marshmallow` 3 emitted through its `validator_failed` error key, so the expected output in `test_manager.py` is unchanged and the surrounding test cases remain consistent in asserting on `marshmallow`'s stock messages. Nothing under `src/` needed changing: the validators there are `marshmallow.validate.Range` and `OneOf`, which already raise. A raising validator also works on `marshmallow` 3, so the supported range is not narrowed, but the same silent acceptance can hit users who wrote their own boolean validators, hence the release notes entry. Signed-off-by: Leandro Lucarella <luca-frequenz@llucax.com>
llucax
enabled auto-merge
September 8, 2026 11:49
Contributor
Author
|
quantities 1.0.3 is out, this is now green. I think we should release this as a "major release", as this breaking change will drag anyone using config schemas too. |
shsms
approved these changes
Sep 8, 2026
Merged
via the queue into
frequenz-floss:v1.x.x
with commit Sep 8, 2026
900fa0e
15 of 17 checks passed
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
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.
CI started failing on
v1.x.xyesterday with three unrelated-looking config test failures. They come from thefrequenz-quantities1.0.2 release, which raised itsmarshmallowfloor to 4 (frequenz-floss/frequenz-quantities-python#107) and thereby draggedmarshmallow4 into our environment for the first time. Marshmallow 4 dropped support for validators that returnFalseinstead of raising, which is what the config test dataclasses were doing, so the validation silently stopped happening.The fix is test-only, but there is a release notes entry because the same silent acceptance hits anyone who wrote boolean validators for their own config dataclasses.
Heads-up for whoever reviews: the docs job on this PR will stay red, for a second and unrelated problem from the same
frequenz-quantities1.0.2 release. That one is a docstring infrequenz-quantitiesusing a relative mkdocstrings cross-reference, which misresolves whenever it is rendered under a path other than the one it was written in, as happens here withBaseConfigSchemainheritingQuantitySchema.TYPE_MAPPING. It cannot be fixed on this side, only worked around by dropping documentation, and frequenz-floss/frequenz-quantities-python#170 already fixes it upstream. #1455 is blocked on the same thing.