FlexMeasures / flexmeasures / 34358655521

85%

push

github

Resolve output-sensor references instead of skipping them (#2507)

* Resolve output-sensor references instead of skipping them

Marking the output sensors with their sign convention silently skipped any reference that
was not already a Sensor object. That covers a failure mode we cannot otherwise explain:
issue #2497 reports the same code raising an AttributeError on a sensor ID, from a path
where the flex-config reached it undeserialized. Skipping such a reference retires the
crash but not the cause; the sensor then keeps the default production-positive convention,
under which the scheduler's consumption-positive values are saved sign-flipped, and the
conflict check that should reject a mismatching attribute at trigger time does not run.

Look the reference up instead, and report one that names no sensor. A field that is not a
sensor reference at all is still left alone, since a custom scheduler is free to use these
field names for something else.

The same silent skip hid three further shapes of an undeserialized flex-config, each of
which now resolves as well: a flex-context in its multi-commodity list form, per-commodity
contexts under the `commodities` key they carry before deserialization (rather than only
`commodity_contexts` after it), aggregate fields under their dashed keys, and a device
flex-model nested in the multi-sensor form.

Closes #2497

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012nk1JXQKQNvKa8iuvdqqWW
Signed-off-by: F.N. Claessen <claessen@seita.nl>

* Add PR link to changelog entry

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012nk1JXQKQNvKa8iuvdqqWW
Signed-off-by: F.N. Claessen <claessen@seita.nl>

* Address review: make the accepted input shapes explicit

The flex-context setter takes a list as well, now that it handles a multi-commodity
flex-context before deserialization, and an output-sensor field may carry its ... (continued)

35 of 36 new or added lines in 1 file covered. (97.22%)

18798 of 22062 relevant lines covered (85.21%)

0.85 hits per line