FlexMeasures / flexmeasures / 30338889679

83%

Build Type

push

github

Committed by web-flow

Commit Message

Fix scheduling jobs failing on a timed_belief UniqueViolation for devices with nested-output-only power sensors (#2360)

* fix: don't emit a device's schedule twice when its power sensor is an output sensor

Since PR #2321, a device that references its power sensor only via a
nested output reference (e.g. {"consumption": {"sensor": N}}) resolves
its power sensor to that output sensor, so it is recognized as a
schedulable device. In StorageScheduler.compute with return_multiple,
that sensor then appeared both as a "storage_schedule" output and as a
"consumption_schedule" output. Both were saved with identical belief
coordinates in the same scheduling-job transaction, guaranteeing a
timed_belief primary-key violation (UniqueViolation) that deterministically
failed the whole job.

Now only the consumption/production output entry is emitted for such a
sensor - the semantically correct one, whose sign conventions are defined
for output sensors (see _build_consumption_production_schedules; the
scheduling service resolves the saving sign via the consumption_is_positive
attribute). As a safety net, all outputs pass through _deduplicate_outputs
before returning, so no sensor can ever appear in more than one output.
The fallback scheduler's return_multiple output now also iterates over the
deduplicated schedule dict instead of the raw per-device sensor list.

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

* docs: changelog entry for duplicate scheduler output fix

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

* docs: reference PR in the DeviceRegistry changelog entry instead

The duplicate-output failure is an unreleased regression of the device
inventory work (PR #2321), so it does not merit a standalone... (continued)

Coverage Stats

13 of 15 new or added lines in 1 file covered. (86.67%)

32 existing lines in 1 file now uncovered.

16005 of 19295 relevant lines covered (82.95%)

0.83 hits per line