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

[Flix6x]

Symptom

A device whose flex-model entry declares its power sensor ONLY via a nested output reference, e.g.

{"consumption": {"sensor": N}, "state-of-charge": {"sensor": M}}

fails every scheduling job (with return_multiple, i.e. the asset-level trigger path) at save time with:

psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "timed_belief_pkey"

The whole scheduling-job transaction rolls back, so the error confusingly claims the key "already exists" while the database afterwards contains none of the rows. Wiping assets does not help — the collision is intra-job. Observed in the field on a fresh partner setup with a battery flex model exactly as above.

Mechanism (origin: PR #2321)

Since PR #2321, _resolve_power_sensor (in flexmeasures/data/models/planning/devices.py) intentionally resolves such a device's power sensor to its nested consumption/production output sensor, so the device is recognized as schedulable rather than misclassified as a stock-only entry.

In StorageScheduler.compute with return_multiple=True, sensor N then appeared twice in the outputs:

1. in storage_schedules (keyed by the resolved device power sensor), and
2. in consumption_production_schedules (N is a declared consumption output sensor).

Both outputs are saved with identical belief coordinates (event_start, belief_horizon, cumulative_probability, sensor_id, source_id) in the same scheduling-job transaction → guaranteed primary-key violation → the job fails deterministically.

The fix

1. Targeted: in the return_multiple output assembly, a sensor that is also a declared consumption/production output sensor is no longer emitted as a storage_schedule entry — only the consumption/production output entry is kept. That entry is the semantically correct one: the sign conventions for output sensors are defined on that path (see the _build_consumption_production_schedules docstring), and the scheduling service resolves the saving sign via the consumption_is_positive attribute stamped on output sensors at job creation. (For a consumption-only device the two entries carried identical data anyway — the full power profile in the scheduler's native sign convention — so no information is lost.)
2. Safety net: compute now passes all outputs through _deduplicate_outputs before returning, so no sensor can ever appear in more than one output entry (first entry wins, later ones are dropped with a logged warning). A duplicate must never reach save_to_db, where it is guaranteed to fail the whole job.
3. The StorageFallbackScheduler's return_multiple output now iterates over the deduplicated schedule dict rather than the raw per-device sensor list (which can name the same sensor twice for devices sharing a sensor).

One existing test (test_multi_device_battery_couples_stock_from_soc_sensor) asserted the old duplicated behavior by looking up the nested-output device's schedule under the name storage_schedule; it now looks up the (single) consumption_schedule entry, keeping its actual intent (stock coupling) unchanged.

Test coverage

New regression test test_scheduling_device_with_nested_output_sensor_only (in flexmeasures/data/tests/test_scheduling_jobs.py): a battery declaring only a nested consumption sensor plus a state-of-charge sensor, scheduled via the asset-level trigger path with a second device (mirroring the field setup). Asserts:

• no sensor appears twice across the scheduler's outputs,
• the nested output sensor's schedule is emitted exactly once, as a consumption_schedule,
• the scheduling job finishes successfully (it used to fail on the timed_belief UniqueViolation), and
• the sensor receives exactly one series of timed_belief rows.

Verified to fail on the pre-fix code (the sensor appeared twice) and pass with the fix.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WtuVTVfL4fQ9QSqbLXmAGD

[read-the-docs-community]

Documentation build overview

📚 flexmeasures | 🛠️ Build #33787777 | 📁 Comparing 455b31b against latest (a3fb811)

  🔍 Preview build  

4 files changed

± changelog.html
± genindex.html
± _autosummary/flexmeasures.data.models.planning.storage.html
± api/v3_0.html

[Copilot]

Pull request overview

This PR fixes a deterministic timed_belief primary-key (UniqueViolation) failure in asset-level (return_multiple=True) scheduling when a device’s power sensor is only referenced via a nested consumption/production output sensor, which previously caused the same sensor to be emitted (and saved) twice in one scheduling job.

Changes:

• Prevent emitting a storage_schedule output when the same sensor is already present as a declared consumption/production output sensor.
• Add a defensive _deduplicate_outputs safety net so a sensor cannot appear in more than one returned scheduler output (duplicates are dropped with a warning).
• Add/adjust regression tests to ensure nested-output-only devices schedule and persist successfully without duplicated outputs.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
flexmeasures/data/tests/test_scheduling_jobs.py	Adds a regression test reproducing the nested-output-only sensor duplication and asserting successful job completion and single belief series persistence
flexmeasures/data/models/planning/tests/test_solver.py	Updates an existing solver regression test to assert the schedule is exposed under consumption_schedule (no longer duplicated under storage_schedule)
flexmeasures/data/models/planning/storage.py	Implements targeted suppression of duplicate storage outputs plus a general output de-duplication safeguard; also avoids duplicate emission in fallback scheduler output assembly
documentation/changelog.rst	Adds a bugfix changelog entry describing the resolved deterministic scheduling failure