FlexMeasures / flexmeasures / 30104917682

83%

push

github

Accept legacy request field names alongside new canonical ones (fixes asset-level force_new_job_creation gap) (#2352)

* Accept legacy request field names alongside new canonical ones

Adds a shared `SupportsLegacyFieldAliases` pre_load mixin
(flexmeasures/data/schemas/utils.py) and applies it so several request
fields now accept both spellings without breaking existing clients:

- `force_new_job_creation` / `force-new-job-creation` on the asset-level
  scheduling trigger (previously only the sensor-level endpoint accepted
  both; this is what flexmeasures-client#218 had to work around
  client-side with server-version sniffing).
- `per_page`/`per-page`, `sort_by`/`sort-by`, `sort_dir`/`sort-dir` on all
  paginated list endpoints.
- `account_id`/`account` and `asset_id`/`asset` on GET /sensors,
  GET /assets, GET /users query filters.

Response fields still need explicit dual-field output for backward
compatibility (can't "accept either" on the way out), but request fields
don't -- this generalizes the one-off alias hook that already existed for
source-account/source-type filtering, so future field renames on the
request side can ship immediately, without waiting for a new API version.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* Fix: don't strip MultiDict semantics when no legacy field is present

_apply_legacy_field_aliases unconditionally rebuilt the incoming request
data into a plain dict, even when none of its declared legacy aliases
were present. That silently broke AssetTriggerSchema.normalize_flex_context_format,
which detects a multi-commodity flex-context list via MultiDict.getlist() --
CI caught this via test_asset_trigger_with_multi_commodity_flex_context
failing (the scheduling job never finished, since flex-context normalization
saw a single dict instead of the intended commodities list).

Now the hook only rebuilds `data` when one of its own legacy keys is
actually present, leaving MultiDict-like inputs untouched otherwis... (continued)

31 of 32 new or added lines in 7 files covered. (96.88%)

15867 of 19147 relevant lines covered (82.87%)

0.83 hits per line